Jeremy Cowgar wrote:
I was hoping to not have to run cmake all the time. I don't want to have
to worry if I edit parser.e, and it ads a new .c file to build, if I am
compiling that new file or not. 1/2 the time I'll never know if parser.e
was updated in such a way.
I'm beginning to think that CMake just isn't up to the task and maybe we
should stick with our three makefiles :-/ With the makefiles, we have a
dependency on the .e files, if they change, then we launch $(MAKE)
generate ... Then when we go to build our project, we do $(MAKE) compile
... This allows us to easily include the .mak file the generator
creates. the first time around it's empty, but it doesn't matter because
when the actual sources are compiled, make is launched, the Makefile is
parsed again and this time (because it's after generation) the .mak file
has content and everything is built automatically. All we do currently
is "make" and everything is handled for us. It's just getting burdensome
maintaining three makefiles.
OK, so your current make solution runs make recursively to solve the
problem.
To get this to work in CMake you will have to run cmake recursively. In
CVS CMake cmake has a --build command that can be used to drive a build.
In 2.6, you can use ctest --build-and-test to cmake and the build tool
automatically.
So, you create a custom command that runs your parser and creates a full
CMakeLists.txt file to build the output of the parser. Then run ctest
--build-and-test on that directory to build the parser output. What is
the output of the parser? Is it a program or a library, or both?
-Bill
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
