[Cmake] RE: [Insight-developers] (ITK) Build Errors terminus. kitware -- W inXP-VC60, library rebuil ds

Tue Mar 18 11:49:33 EST 2003

I don't think a custom command would do the trick.
We could add a target similar to ALL_BUILD, ALL_LIBRARY_BUILD
that would build all the libraries in a project but not the executables.
I assume the reason you don't do ALL_BUILD each time is because
ITK has too many executables, and it takes too long to link.

We could simulate that without changing cmake by adding a dummy executable
that linked all the libraries in ITK, and call the executable ALL_LIBRARIES.

-Bill

At 10:39 AM 3/18/2003, Miller, James V (Research) wrote:
>So this goes down as another bug in DevStudio?
>
>Could CMake custom commands be used to force these "static" inter-library
>dependencies to trigger? I have been bit by this many times.  Change some
>code, rebuild a single target, do not see the change at runtime... all
>because the code I changed was in a different target (library) then the one
>I rebuilt. For instance, I could change something in DICOMParser, rebuild
>IO, (not pay attention to the fact that it didn't rebuild), then jump over
>to another application (in a different project) and relink my executable. I
>would not expect CMake to make the connection between two different
>DevStudio projects, so I do not mind jumping between two projects to build a
>library and then build an application.  However, it would be nice if CMake
>could protect me from myself where I modify something like DICOMParser but
>only tell IO to rebuild.
>
>Usually after I get bit by this I retrain myself to always build using
>ALL_BUILD. But I make this pattern of mistakes every few months....
>
>
>
>> -----Original Message-----
>> From: Bill Hoffman [mailto:bill.hoffman at kitware.com]
>> Sent: Monday, March 17, 2003 4:38 PM
>> To: Miller, James V (Research); 'Ken Martin'; Miller, James V
>> (Research); 'Insight-developers (E-mail)'; 'CMake developers (E-mail)'
>> Subject: Re: [Cmake] RE: [Insight-developers] (ITK) Build Errors
>> terminus.kitware -- W inXP-VC60, library rebuil ds
>> 
>> 
>> OK, With DevStudo 6 and 7, static libraries can not depend on 
>> other static libraries.   By adding the dependency, it causes 
>> the project to link the two libraries together.
>> 
>> So, if you have this:
>> 
>> libA dependsOn libB, libC
>> libB dependsOn libC
>> exeC dependsOn libB, libA, libC
>> 
>> Then when you link exeC, you will get duplicate symbol 
>> warnings, because
>> it will have the .o files from C duplicated in libB and libA.
>> 
>> So, with visual studio 6 and 7, you can not chain static libraries.
>> However, if you build an executable that uses the libraries, it will
>> chain correctly.
>> 
>> If you did the "add files to project", for all the depend 
>> information, you
>> would see the problem.   If you only do it for one of them it 
>> appears to work,
>> but if you look closely, you will see that it is creating 
>> combo libraries.
>> 
>> So, for your example, if you built IOTests, it would 
>> correctly build both
>> the DICOMParser and the IO library.   But, building the IO 
>> library will
>> not cause the DICOMParser to rebuild.
>> 
>> 
>> -Bill
>> 
>> 
>> At 04:02 PM 3/17/2003, Miller, James V (Research) wrote:
>> >Well here a test that I ran the other day.  It happens to 
>> mimic the problem that Matt was having.  In ITK, there is a 
>> library under Utilities called DICOMParser.  In Code/IO is 
>> there is a class that uses this library called 
>> itkDICOMImageIO2. If I make a change to 
>> Utilities/DICOMParser/DICOMFile.cxx and tell DevStudio to 
>> rebuild the IO library, it does not recompile DICOMFile.cxx.  
>> It instead thinks that Utilities/DICOMParser is up to date 
>> and links the IO library using the old DICOMParser lib.
>> > 
>> >Matt added the DICOMParser library to the IO project using 
>> "Add Files To Project..." and then a change to DICOMFile.cxx 
>> does cause the IO library to build.
>> > 
>> >Otherwise, I would fathom that you are correct in that the 
>> incremental linker is trying to incrementally link an old 
>> executable with a new library and complaining.
>> > 
>> >Sorry for the specific example. But I am in the rush to talk 
>> to someone.....
>> > 
>> >Jim
>> > 
>> >-----Original Message-----
>> >From: Ken Martin [mailto:ken.martin at kitware.com]
>> >Sent: Monday, March 17, 2003 3:11 PM
>> >To: 'Miller, James V (Research)'; 'Insight-developers 
>> (E-mail)'; 'CMake developers (E-mail)'
>> >Subject: RE: [Insight-developers] (ITK) Build Errors 
>> terminus.kitware -- WinXP-VC60, library rebuil ds
>> >
>> >I just checked and as far as I can see CMake is setting up 
>> the target dependencies (and chaining them) correctly for 
>> both VS6 and VC7. (it is easy to verify from VS just look at 
>> the project dependencies). Having seen this type of problem 
>> before on occasion, my suspicion is that this is a bug in the 
>> VS incremental linker or VS dependency checks.  Unfortunately 
>> the offending dashboard was cleaned so there is little 
>> remaining evidence. Looking at the dashboard it seems clear 
>> that ITKCommon was rebuilt (the symbols are missing as they 
>> should be) the problem seems to be that some examples still 
>> think that the symbols should be there. So either the 
>> executable is screwed up (VS is trying to relink the 
>> executable) or the specific test .obj file (Smooth something 
>> or another in this case) has not been rebuilt, but that is a 
>> VS dependency issue. It would have been nice if we could have 
>> checked if the Smooth&obj was up to date or not.
>> >
>> > 
>> >
>> >Ken
>> >
>> > 
>> >
>> > 
>> >
>> >-----Original Message-----
>> >From: insight-developers-admin at public.kitware.com 
>> [mailto:insight-developers-admin at public.kitware.com] On 
>> Behalf Of Miller, James V (Research)
>> >Sent: Monday, March 17, 2003 2:18 PM
>> >To: Insight-developers (E-mail); CMake developers (E-mail)
>> >Subject: [Insight-developers] (ITK) Build Errors 
>> terminus.kitware -- WinXP-VC60, library rebuil ds
>> >
>> > 
>> >
>> >The build errors on terminus.kitware are referencing methods 
>> that I removed from the system on Friday.  These symbols were 
>> never used, so I deleted them to simplify the code.
>> >
>> > 
>> >
>> >Since we have these build errors, it looks VC6 did not 
>> rebuild all the libraries or an old object file is lying around.
>> >
>> > 
>> >
>> >The reason I bring this up on the list(s) is that we have 
>> had a lot of problems recently with VC6 building applications 
>> (examples) where the dependent libraries are not being 
>> rebuilt.  Here is an example:  change some code in library A. 
>>  Library B links with library A.  Executable C links with 
>> library B.  If you just tell VC6 to build executable C, then 
>> library A does not get rebuilt.  If you build from the top 
>> using the ALL_BUILD target, then everything works fine. I 
>> think Matt discovered if he added the other libraries to the 
>> particular projects (using "Add files to project"), then the 
>> rebuilds are triggered properly.  However, this information 
>> is lost the next time CMake is run.
>> >
>> >Have other people seen this? Can CMake add the link 
>> libraries that an executable uses that are also built by the 
>> workspace to the dependent projects? Or is this necessary?
>> >
>> >I think I have seen this same behavior on VC7.
>> >
>> >Jim Miller 
>> >_____________________________________
>> >Visualization & Computer Vision
>> >GE Research
>> >Bldg. KW, Room C218B
>> >P.O. Box 8, Schenectady NY 12301
>> >
>> ><mailto:millerjv at research.ge.com>millerjv at research.ge.com
>> >
>> >james.miller at research.ge.com
>> >(518) 387-4005, Dial Comm: 8*833-4005, 
>> >Cell: (518) 505-7065, Fax: (518) 387-6981 
>> >
>> > 
>> >
>> > 
>> 
>> 
>> 
>_______________________________________________
>Cmake mailing list
>Cmake at public.kitware.com
>http://public.kitware.com/mailman/listinfo/cmake 