Continuous incremental C++ build setup
I'm trying to setup a continuous integration build for a customer which migrates C++ developments from another SCM to RTC.
This is a Makefile build, I have followed the instructions in the wiki page : https://jazz.net/wiki/bin/view/Main/CppBuild I use the following settings in the Build definition : - Delete directory before loading : UNCHECKED - Accept latest changes ... CHECKED - Build only if there are changes .. CHECKED The build is automatically scheduled on a regular basis. If one developer delivers a change set to the common stream, the next scheduled build executes, as expected. My problem is that make recompiles everything because the artefacts produced by the previous build (*.o , *d, *.a, binaries, which are all ignored ressources) have been deleted by the hierarchy update process which occurs automatically at the beginning of the build. This is not a behaviour I would normally expect. I there a workaround for that ? Did I miss something in the setup ? |
8 answers
Hi Jean-Michel,
The load should not delete any files that aren't under version control. Are you sure the .o files are actually getting deleted by the load phase of JBE, or could it be that the build script is doing a clean? Another possibility is that the *.cpp files have newer timestamps after the load, so it thinks it needs to recompile everything. But that shouldn't be happening either. The 'merge load' that we do should only download content for new or changed files, so existing files should not even get touched. For more details on how the load works, see: https://jazz.net/wiki/bin/view/Main/BuildFAQ#LoadingJazzSCM Regards, Nick |
|
Hi Nick,
I'm back to this problem.. I cant' solve it. I upgraded to the latest Ifix5. I run on a RedHat Enterprise. The build is scheduled automatically, it runs as expected only when a change has been delivered to the stream. It runs in a dedicated workspace on this stream. No other build is running. The makefile works incrementally as expected in the developer's Eclipse workspace. I confirm that : - 'Delete dir before build' is UNCHECKED - 'Accept latest changes..' is CHECKED - 'Build only if...' is CHECKED - unchanged file stamps are not changed by the hierarchy update (cool !) - no 'clean' target is executed But .. everything is recompiled since the production files (*.o) which remained in the hierarchy from the previous build are removed from the hierarchy by the update. I can see that they suddenly disappear from the build hierarchy when the build starts.. |
|
Hi JM,
I was able to reproduce your scenario. Sorry, I was mistaken above. The merge load does delete other files not under source control, unless they are in the ignores list. Try this: In the RTC client: - at top level in the project (or source folder), create a foo.o file - select it and choose Team > Add to Ignore List... - choose the 'Resources with selected extension' and 'Recursively ignore items below' options - click OK - this creates a .jazzignore file (if you don't see it, check the filtering options in the view) - check in the .jazzignore file (so it gets maintained in SCM and loaded on the build machine) - delete the foo.o file Then, restart JBE. While investigating this, I saw a defect whereby JBE caches the ignore files in memory and doesn't update when they're changed. Then, run a build. It may still delete the .o files the first time since the .jazzignore file isn't on disk yet. If so, then try again. The .o files should now remain. Of course, you'll need to be careful when you remove or rename .c / .cpp files, since the .o files with the old names will remain. You might want to periodically run a clean build that deletes everything. |
|
We're tracking the caching issue in 139553: JBE caches .jazzignore files and never invalidates the cache, and I've cc'ed you.
|
|
Thanks a lot for the information. I finally could setup the continuous incremental C++ build for my customer. May I suggest that the caching issue be fixed asap. It is quite uncomfortable to have to restart the build engine every time someone modifies one of the .jazzignore files.
|
|
Great, glad to hear. Regarding the ignores list caching issue, I agree that it is annoying but since there's a straightforward workaround it's hard for me to argue for including it in an iFix. The SCM team is working on a fix for 3.0.1 (summer 2011). Do you hit the problem continually? I mean, now that you have it set up to ignore .o files (and possibly others), do you expect to have to make further changes to the ignores list(s)?
|
|
In fact, the current customer is now aware of the problem and is OK with that. This is a small team, in the same office, and they can deal with the workaround. But it may be more uncomfortable with large projects. Also, when I deploy one tool, I don't like to have to explain each customer "well, there is a bug here, and the workaround is ..". The product is so great .. ! It is just like a small spot on his nose !
|
|
Understood. Thanks for clarifying, and sorry for the inconvenience.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.