Re: [CMake] Dependency checking for D
Date: Thu, 7 Feb 2008 19:30:08 +0100 From: Alexander Neundorf [EMAIL PROTECTED] On Wednesday 06 February 2008, Tim Burrell wrote: Hi there, I'm one of the maintainers of the CMake module for the D programming language (http://dsource.org/projects/cmaked), and currently the module works really well, with one exception: dependency checking. Since D uses an import method which is very similar to java, I'm wondering if it would be possible, or if there'd be any way to convince CMake to use the java dependency scanner when compiling D files? Failing that, is the dependency system user extendable in any way? Yes. But not that much. The C/C++ dependency scanner can be influenced by setting the variable CMAKE_language_INCLUDE_REGEX_SCAN to another regular expression which matches the language (D). I don't know if this would be good enough for D. Then there are the Java and Fortran dependency scanners. I don't know much about them, if you want to influence them probably something has to be coded. I don't know how similar to D they are. The D import statement is so similar to Java that I think it might (mostly) work. That being said, if I want to try to influence the C++ scanner, are there docs anywhere on that INCLUDE_REGEX_SCAN? I did a quick search but didn't turn up much. I assume the C++ scanner wouldn't work well for Java style imports otherwise there wouldn't be a separate scanner for Java eh? Thanks, Tim. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Dependency checking for D
Date: Thu, 7 Feb 2008 19:38:18 +0100 From: Maik Beckmann [EMAIL PROTECTED] While C and C++ dependency tracking uses regular expressions the java and fortran pendants use lex/yacc generated parsers. I don't know D very well, but if the language specification forces the import directives to be at the very top of each file like does java, well, than the java parser might be a good bet. The D imports mostly work exactly like Java: import module.submodule.Class; That'll look for the file module/submodule/Class.d from all of the compiler include paths. At the top of nearly every D file is a line: module ModuleName; Then after that comes the import statements. Would this module declaration cause problems for the Java scanner? There are some other potential problems though, like D's imports are a bit more flexible than Java's, allowing things like public and private imports: public import module.Class; It also has the ability to rename imports: import RenamedModule = module.Class; Even if these do cause problems, I still think that any dependency checking would be better than no dependency checking, so... given that I'd like to give this a shot, is there a way to convince the Java dep checker to look for D files instead of Java? Thanks, Tim. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Dependency checking for D
Hi there, I'm one of the maintainers of the CMake module for the D programming language (http://dsource.org/projects/cmaked), and currently the module works really well, with one exception: dependency checking. Since D uses an import method which is very similar to java, I'm wondering if it would be possible, or if there'd be any way to convince CMake to use the java dependency scanner when compiling D files? Failing that, is the dependency system user extendable in any way? Thanks, Tim. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake dependency checking
Hi, I have the following directory structure ProjName | - src | -lib | -app if I execute cmake -DBUILD_TYPE=Debug at the app level then the linking fails with missing lib. Obviously this because the lib is not compiled. Is there any way for me to detect that when I do cmake in the app folder that lib is not compiled and then compile for the linking to work. BTW if I do cmake @ the src level then everything works fine. Waiting for your replies and thanking you in advance. Regards, Aj ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake dependency checking
On Jan 8, 2008 1:47 PM, Ajay Divekar [EMAIL PROTECTED] wrote: Hi, I have the following directory structure ProjName | - src | -lib | -app if I execute cmake -DBUILD_TYPE=Debug at the app level I don't have any experience running CMake from subdirectories of a source tree. I'll let others comment on that. then the linking fails with missing lib. Obviously this because the lib is not compiled. Is there any way for me to detect that when I do cmake in the app folder that lib is not compiled and then compile for the linking to work. Do you have a TARGET_LINK_LIBRARIES command for app, so that lib will be linked? BTW if I do cmake @ the src level then everything works fine. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] dependency checking
I've been trying to find a good explanation of how the /fast target works online? Is there a place where the exact behavior documented? Also my concern is that adding a source file to CMakeLists.txt file triggers a rebuild of all source files? Can this be averted by having cmake discover the source files instead of me specifying them? Is there a better way of preventing rebuilds when I know that my changes don't invalidate the object files I already have compiled? Regards, Juan -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
On Thursday 09 August 2007 12:57, Juan Sanchez wrote: I've been trying to find a good explanation of how the /fast target works online? Is there a place where the exact behavior documented? Also my concern is that adding a source file to CMakeLists.txt file triggers a rebuild of all source files? Can this be averted by having No, it doesn't. You really only get rebuilds if they are required (e.g. if a header changes or if some compile flag is changed). Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
I just added a source file to the list of sources in my library and now it is recompiling every source file in that library. I don't feel rebuilding the other source files is necessary and I'd like a way to tell cmake to trust me and that any object files I have are still good. Regards, Juan Alexander Neundorf wrote: On Thursday 09 August 2007 12:57, Juan Sanchez wrote: I've been trying to find a good explanation of how the /fast target works online? Is there a place where the exact behavior documented? Also my concern is that adding a source file to CMakeLists.txt file triggers a rebuild of all source files? Can this be averted by having No, it doesn't. You really only get rebuilds if they are required (e.g. if a header changes or if some compile flag is changed). Bye Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
Juan Sanchez wrote: I just added a source file to the list of sources in my library and now it is recompiling every source file in that library. I don't feel rebuilding the other source files is necessary and I'd like a way to tell cmake to trust me and that any object files I have are still good. Either that is a bug, or a compiler flag has changed. CMake should only rebuild object files if the source (including headers) for that file changes, or if the flags used to compile that object file changes. make -d can be used to figure out why make is rebuilding the object files. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
Hi Bill,
I ran a test and figured out what is triggering the problem. The
problem is that I have SET_SOURCE_FILES_PROPERTIES which operates on
${SRCS}. By adding to ${SRCS} it triggers the rebuild of all of the
files listed, and not just of the one I added.
If I comment out SET_SOURCE_FILES_PROPERTIES, I can add or remove files
from ${SRCS} without retriggering costly rebuilds.
Is there any way to change this behavior? Unfortunately the project I
am porting has source files for multiple libraries in the same
directory. I'd hate to have to list each file individually.
Regards,
Juan
PROJECT(main)
SET (SRCS a.cc b.cc c.cc d.cc e.cc f.cc g.cc)
ADD_EXECUTABLE(a ${SRCS})
ADD_LIBRARY(b ${SRCS})
SET_SOURCE_FILES_PROPERTIES (
${SRCS}
COMPILE_FLAGS -Wall
)
Bill Hoffman wrote:
Juan Sanchez wrote:
I just added a source file to the list of sources in my library and now
it is recompiling every source file in that library. I don't feel
rebuilding the other source files is necessary and I'd like a way to
tell cmake to trust me and that any object files I have are still good.
Either that is a bug, or a compiler flag has changed. CMake should
only rebuild object files if
the source (including headers) for that file changes, or if the flags
used to compile that object
file changes.
make -d can be used to figure out why make is rebuilding the object files.
-Bill
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
Juan Sanchez wrote: I just added a source file to the list of sources in my library and now it is recompiling every source file in that library. I don't feel rebuilding the other source files is necessary and I'd like a way to tell cmake to trust me and that any object files I have are still good. What version of CMake are you running? Simply adding a source file to a library is not enough to trigger a rebuild of that library although it will certainly cause the library to relink. Are you sure you didn't change a common header file or something like that at the same time? If you change the preprocessor definitions or include path the Makefile generator will happily recompile all of the code that needs to be recompiled. This does not happen on Visual Studio however due to limitations with Visual Studio. On a related note: There is a way to disable recompilation based on rule dependencies buried in the useful variables section of the CMake wiki. Simply defining the variable CMAKE_SKIP_RULE_DEPENDENCY temporarily in your CMakeLists.txt will cause CMake to stop the rebuilding of source files that need to be rebuilt. It's best to use this only temporarily and only when you really don't want your development interrupted by a rebuild of your entire source tree. You should remove the variable as soon as you have time to recompile. Not doing so could be dangerous as you might think things are working but not realize the addition of a preprocessor definition or modification of the include path causes things to break. -- Philip Lowman Simulation Development Engineer, Modeling and Simulation Technology General Dynamics Land Systems http://www.gdls.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
Juan Sanchez wrote:
Hi Bill,
I ran a test and figured out what is triggering the problem. The
problem is that I have SET_SOURCE_FILES_PROPERTIES which operates on
${SRCS}. By adding to ${SRCS} it triggers the rebuild of all of the
files listed, and not just of the one I added.
If I comment out SET_SOURCE_FILES_PROPERTIES, I can add or remove files
from ${SRCS} without retriggering costly rebuilds.
Is there any way to change this behavior? Unfortunately the project I
am porting has source files for multiple libraries in the same
directory. I'd hate to have to list each file individually.
Regards,
Juan
PROJECT(main)
SET (SRCS a.cc b.cc c.cc d.cc e.cc f.cc g.cc)
ADD_EXECUTABLE(a ${SRCS})
ADD_LIBRARY(b ${SRCS})
SET_SOURCE_FILES_PROPERTIES (
${SRCS}
COMPILE_FLAGS -Wall
)
OK, this is a bug... Please create a bug report www.cmake.org/Bug.
Include your example if you could. The problem is a comment in the
flags.make file for each .o file with custom flags. I see no reason to
put that comment in the file.
So, to get around the problem you have two choices:
1. use CMAKE_CXX_FLAGS instead.
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wall)
That will change all targets in that directory and below.
2. set CMAKE_SKIP_RULE_DEPENDENCY to true.
I would recommend 1, as 2 will cause trouble if you really do change
flags.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
The problem still exists after adding the PROPERTIES keyword.
Thanks,
Juan
Alexander Neundorf wrote:
On Thursday 09 August 2007 13:32, you wrote:
Hi Bill,
I ran a test and figured out what is triggering the problem. The
problem is that I have SET_SOURCE_FILES_PROPERTIES which operates on
${SRCS}. By adding to ${SRCS} it triggers the rebuild of all of the
files listed, and not just of the one I added.
If I comment out SET_SOURCE_FILES_PROPERTIES, I can add or remove files
from ${SRCS} without retriggering costly rebuilds.
...
SET_SOURCE_FILES_PROPERTIES (
${SRCS}
COMPILE_FLAGS -Wall
)
I didn't test, but here the PROPERTIES keyword is missing. Is it just a
copy'n
paste error or does it still happen if you insert it ?
Alex
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency checking
On Thursday 09 August 2007 13:32, you wrote:
Hi Bill,
I ran a test and figured out what is triggering the problem. The
problem is that I have SET_SOURCE_FILES_PROPERTIES which operates on
${SRCS}. By adding to ${SRCS} it triggers the rebuild of all of the
files listed, and not just of the one I added.
If I comment out SET_SOURCE_FILES_PROPERTIES, I can add or remove files
from ${SRCS} without retriggering costly rebuilds.
...
SET_SOURCE_FILES_PROPERTIES (
${SRCS}
COMPILE_FLAGS -Wall
)
I didn't test, but here the PROPERTIES keyword is missing. Is it just a copy'n
paste error or does it still happen if you insert it ?
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
