build-automation

I've been pushing for continuous integration at my company since I joined 5 months ago, but having seen the type of applications we work on I'm starting to think that it might not be worth the effort of setting up each and every project for continuous integration. If you work in a development department where the average project takes 2-3 weeks and once it's deployed you seldom if ever have to worry about it, is continuous integration worth the hassle of setting it up? Probably depends on your process. If you have unit tests that cover your code, then continuous integration is worth every bit.

In my C# ClickOnce application, there is an auto-incremented publish version in the Project -> Properties -> Publish tab. I'd like to display that version in my menu Help -> About box, but the code I'm using apparently accesses the assembly Version, which is different. The Assembly Version can be changed manually in the Project -> Properties -> Application -> Assembly Information dialog. So for now, every time before I publish I've been copying the publish version to the assembly version, so my dialog shows the current version of the application. There must be a better way to do this. All I

I'm trying to set up our build process in hudson. Job 1 will be a super fast (hopefully) continuous integration build job that will be built frequently. Job 2, will be responsible for running a comprehensive test suite, at a regular interval or triggered manually. Job 3 will be responsible for running analysis tools across the codebase (much like Job 2). I tried using the "Advanced Projects Options > use custom workspace" feature so that code compiled in Job 1 can be used in Job 2 and 3. However, it seems that all build artifacts remain inside that Job 1 workspace. I'm I doing this right? Is

How do I set up CMake to recursively scan a given directory and determine the list of source files? My project is a shared library. I have a folder structure similar to this: / src/ # Source files in an arbitrary tree include/ # Headers, tree mirrors that of the src/ folder examples/ # Executable code examples that link against the library CMakeLists.txt I want CMake to recursively scan src and include and determine the list of source and header files in my project, regardless of the directory structure. I also want to avoid: Polluting the src/ and include/ directories with endless CMakeLists

I once worked on a C++ project that took about an hour and a half for a full rebuild. Small edit, build, test cycles took about 5 to 10 minutes. It was an unproductive nightmare. What is the worst build times you ever had to handle? What strategies have you used to improve build times on large projects? Update: How much do you think the language used is to blame for the problem? I think C++ is prone to massive dependencies on large projects, which often means even simple changes to the source code can result in a massive rebuild. Which language do you think copes with large project dependency

We decided to switch from VS integrated setup to WiX. However, what we currently do is use projects output files as the input for the setup project. This lets us easily add Application Files to a directory (for images, samples, and other resources...) and those files are automatically added to the setup when we build. I could not find any similar feature in WiX. WiX seems to require one Directory entry and one File entry for each and every directory and file. This would require us to change the WiX source everytime a file is added which, to my eyes, is prohibitive since we have so many of them

What does it mean to build a solution/project/program? I want to make sure I have my definitions correct (so I don't sound like a idiot when conversing). In IDE's, you can (correct me if I'm wrong) compile source-code/programming-code into computer-readable machine code. You can debug a program, which is basically stepping through the program and looking for errors. But what exactly does building a program do? In VS I'm aware that when you build a program it produces an executable file in a debug folder. Any hard-core tech definitions of what it means to build a program? This does not