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
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.
Brandon Van Every
William A. Hoffman wrote:
I got this error:
make: *** No rule to make target `match.c', needed by `static/CMakeFiles/libchicken-static.dir/depend.make.mark'. Stop.
make: *** [static/CMakeFiles/libchicken-static.dir/all] Error 2
make: *** 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.
Brandon Van Every