[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
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. Cheers, Brandon Van Every 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 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
[Chicken-users] Re: CMake problem on Linux
At 03:48 PM 9/6/2006, Brandon J. Van Every wrote: felix winkelmann wrote: Excellent, Bill! Thanks for the quick and helpful solution. On 9/6/06, Bill Hoffman [EMAIL PROTECTED] wrote: The reason it is only broken on linux is this: IF(MINGW) You need the same fix on all os's. Further good news is these problems are going away in Chicken 2.4.4. I did not think of this bug because I thought it was just a Windows bug, not all OSs. Did you mean CMake 2.4.4? If so, what is the fix, because CVS CMake still has the issue. Is there something you need to change in the CMakeLists.txt for chicken? -Bill ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: CMake problem on Linux
At 03:59 PM 9/6/2006, Brandon J. Van Every wrote: Um, yeah, that. :-) If so, what is the fix, because CVS CMake still has the issue. It does? Well, bother. I thought Brad told me it was patched already. I haven't verified it, been too busy. I think you have to set CLEAN_DIRECT_OUTPUT to 1 as a target property for his change to work. Is there something you need to change in the CMakeLists.txt for chicken? The workarounds for CMake 2.4.3 are fine on both MinGW and Cygwin. It is straightforward to extend them to all OSs. Might be best for now. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
