[Chicken-users] Re: CMake problem on Linux should be solved
At 05:50 PM 9/8/2006, Brandon J. Van Every wrote: >Drat. I was hoping that file level dependencies would cross subdirectory >boundaries. They seem to do it on MinGW, Cygwin, and VS71 - or else the build >order just happens to work on those platforms. Do file dependencies not cross >subdirectories on Linux? Even on the Windows targets, I had to specify the >file dependencies as GENERATED to get CMakeSetup to quit complaining. >Previously I've not had to do that, but previously, .scm --> .c was always >done in the same directory. > >I can put custom targets back in to force the .c files to be built. But I'd >like to know if this is a bug or expected behavior. Lately I've been avoiding >"target wrapping paranoia," that is, the tendency to wrap up all file >dependencies in custom targets for fear that file dependencies won't be >honored. It'll be nice if someday the file dependencies and target >dependencies are handled in the same way. The problem only shows up with parallel builds. The file level depends do not cross sub directories. You should be able to fix this with a target level add dependency. This will potentially show up in newer versions of Visual studio as well the do parallel builds by default, and with the dual core cpus out there it is likely someone will see it. -Bill ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: CMake problem on Linux should be solved
At 11:51 AM 9/8/2006, William A. Hoffman wrote: >I got this error: > >make[2]: *** No rule to make target `match.c', needed by >`static/CMakeFiles/libchicken-static.dir/depend.make.mark'. Stop. >make[1]: *** [static/CMakeFiles/libchicken-static.dir/all] Error 2 >make[1]: *** Waiting for unfinished jobs Further update, that only happens with a -j2 parallel build. So, there must be a missing ADD_DEPENDENCY. My guess is match.c is a generated file, and it is generated as part of some other target that happens to be built before some other target that uses it? I have not looked into it, so I am not sure. But to be clear: make -j2 on a clean build tree fails with the above error make on clean build tree works. -Bill ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: CMake problem on Linux should be solved
I got this error: make[2]: *** No rule to make target `match.c', needed by `static/CMakeFiles/libchicken-static.dir/depend.make.mark'. Stop. make[1]: *** [static/CMakeFiles/libchicken-static.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs At 09:39 PM 9/7/2006, Brandon J. Van Every wrote: >CMake 2.4.3 has a bug where static and dynamic libraries clobber each other >during the build if they have the same rootname. The bug affects all OSes. >Previously I thought it only affected Windows, and I implemented hacks during >the INSTALL to get around it. Felix reported a problem on Linux and Bill of >Kitware confirmed that it's the same bug. > >I decided it is too complicated to do more INSTALL hacks, as I don't really >know what suffixes are apropos on Linux or arbitrary OSes in general, nor do I >have the ability to test them. So, static libraries are now built in a >/static subdirectory. This took some refactoring of CMakeLists.txt. It >wasn't trivial but it was doable, about a day's work. The results are now in >Darcs. I have confirmed that VS 7.1, MinGW, and Cygwin all build and install >just fine now. I am projecting that Linux will build and install just fine >now as well, since it will go through the same code path as the MinGW build. > >I await your tests. > > >Cheers, >Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
