[Cmake] RE: [Insight-developers] (ITK) Build Errors
terminus. kitware -- W inXP-VC60, library rebuil ds
Bill Hoffman
bill.hoffman@kitware.com
Tue, 18 Mar 2003 11:49:33 -0500
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@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@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@public.kitware.com
>> [mailto:insight-developers-admin@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@research.ge.com>millerjv@research.ge.com
>> >
>> >james.miller@research.ge.com
>> >(518) 387-4005, Dial Comm: 8*833-4005,
>> >Cell: (518) 505-7065, Fax: (518) 387-6981
>> >
>> >
>> >
>> >
>>
>>
>>
>_______________________________________________
>Cmake mailing list
>Cmake@public.kitware.com
>http://public.kitware.com/mailman/listinfo/cmake