Re: [CMake] out-of-source build and generated files
Original-Nachricht
Datum: Thu, 29 Jun 2006 22:38:13 -0400
Von: Scott Amort [EMAIL PROTECTED]
An: CMake@cmake.org
Betreff: [CMake] out-of-source build and generated files
Hi,
First off, thanks to the CMake developers and responders on this list,
my transition to CMake has been almost completely painless, and best of
all, very fast!
I have one more question, however. Now that my newly-CMaked project
works, I've been experimenting with out-of-source builds. I have run
into a problem relating to generated files. My library makes use of an
ANTLR generated lexer/parser, and as it is still quite new and
developing, I include the ANTLR grammar files and generate the source
files at build time with an ADD_CUSTOM_COMMAND. Works great. Except,
with an out-of-source build, these newly generated files populate the
source directory, which is what I was trying to avoid with the
out-of-source build. Has anyone else encountered this situation? I'm
not really sure how to solve it - if I alter the ADD_CUSTOM_COMMAND to
generate the files in the build directory, they aren't where the
compiler expects them to be, and I can't list them in the CMake
ADD_LIBRARY command as being in the build directory as they don't exist
there yet. Any thoughts?
If you generate files using ADD_CUSTOM_COMMAND(), you should always use full
paths for the generated files, i.e.
${CMAKE_CURRENT_BINARY_DIR}/generatedsource.cpp , both in the
ADD_CUSTOM_COMMAND() and in the list of source files.
Bye
Alex
--
Feel free – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Forcing C++: What Causes VC Warning D4025 : overriding /TP with /TC
Code is a mix of .c and .cpp files. Some of the directories contain only
.c files.
...
SET(CMAKE_C_COMPILER ${CMAKE_CXX_COMPILER})
SET_TARGET_PROPERITES( tgt PROPERTIES LINKER_LANGUAGE CXX)
Warning D4025 : overriding /TP with /TC
I reported the same bug (05.06.2006 21:33), too.
Will already fixed it in CVS.
Jan,
Thank you for this info. I'm now looking at something that seems relevant,
but this look has raised more questions in my mind.
I am currently running the binary distro of 2-4-2
Inside:
cmLocalVisualStudio7Generator.cxx
Revision: 1.125.2.3, Sun May 14 19:22:42 2006 UTC (6 weeks, 4 days ago) by
hoffman
Branch: CMake-2-4
CVS Tags: CMake-2-4-2
Changes since 1.125.2.2: +107 -62 lines
I find:
// if the source file does not match the linker language
// then force c or c++
if(linkLanguage lang strcmp(lang, linkLanguage) != 0)
{
if(strcmp(lang, CXX) == 0)
{
// force a C++ file type
compileFlags += /TP ;
}
else if(strcmp(lang, C) == 0)
{
// force to c
compileFlags += /TC ;
}
}
If I'm reading this right (?), this is the CAUSE of the problem - i.e. this
is where the trailing /TC gets added at the end of the build command,
when lang == C, which is when the file has a .c extension. Is this right
so far?
then I find, in this later version, ( later than 2-4-2, meaning it's not in
my CMake executable, yes?) :
cmLocalVisualStudio7Generator.cxx
Revision 1.135 - (view) (download) (as text) (annotate) - [select for diffs]
Tue Jun 6 16:01:23 2006 UTC (3 weeks, 2 days ago) by hoffman
Branch: MAIN
ENH: fix /TP for c code
Is this the fix you refer to?
I looked at the diff for these two versions, and see that 1.135 adds code
down around line 1167 dealing with flags in some way that I can't quickly
decipher, but which has no immediately recognizable reference to /TC or
/TP .
If this is the fix, and it works, I'd be interested to understand how it
works.
If this is not the fix, I'm sorry for getting it wrong, and I'd welcome a
pointer to the correct revision.
Finally, it seems that binary distros are prepared relatively infrequently.
Is getting this:
SET(CMAKE_C_COMPILER ${CMAKE_CXX_COMPILER})
SET_TARGET_PROPERITES( tgt PROPERTIES LINKER_LANGUAGE CXX)
to work as intended in these circumstances not judged important enough to
warrant a 2-4-3 build?
It would be helpful, if possible, to be able to refer my development
partner(s) to a binary distro of CMake that handles this situation.
If I have to bite the bullet and start compiling CMake's own source code,
and getting partner(s) to do same, I imagine we can and will, but if
generating a 2-4-3 binary at home base is not hard, perhaps it would be
worthwhile and save some people from extra work and possible issues in the
field.
- Steve
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Installing CMake for multiple platforms
The directory stucture in your email has font issues or something. Can you re-post in plain text? \BUILDTOOLS\CMAKE ââââEdmTemplates ââââhpux â ââââbin â ââââinclude â ââââModules â â ââââPlatform â ââââTemplates ââââWin32 ââââbin ââââinclude ââââModules â ââââPlatform ââââTemplates -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Installing CMake for multiple platforms
William A. Hoffman wrote: The directory stucture in your email has font issues or something. Reading it in character encoding Uncode (instead of western works here. Jan. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] VS 8 CMake 2.4.2
Hi, Previously problems using CMake with Visual Studio 8 were reported. They were reported with Visual Studio 2005 Express, but I encountered them too with the full Visual Studio 8 version. CMake failed to compile the test program and the output showed that OLDNAMES.lib could not be found. What happened is the following: When installing VS8 I removed the static runtime libraries from the installer selection since we always link against the runtime DLLs. Apparently this is not supported by CMake. The solution is to either add the static runtime libs to your installation or add /ignorlib:OLDLIBNAMES.lib to the compiler flags. I choose the first solution, because it's the easiest. Changing the default compiler flags requires some fiddling with cmake files in the installation. Best regards, Kris +-+-+- Email Confidentiality Footer +-+-+- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not print, retain, copy nor disseminate this message or any part of it to anyone and you should notify the sender by reply email and destroy this message. Neglecting this clause could be a breach of confidence. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that are not related to the official business of my firm shall be understood as neither given nor endorsed by it. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Regex changes between cmake 2.0.6 and 2.4.2 ??
Hi,
I was running my build macros in the latest CMake (2.4.2) and encountered very
strange errors. With some debug printing I discovered that the new CMake
version behaves differently regarding RegEx testing compared to the version
2.0.6 that we currently use.
This is a summary of what we do:
SET(RegexAbsoluteDir ^([a-zA-Z][:])?[/])
#--- Make directories absolute
SET(DirList)
PRINT_MESSAGE(9 WordList ${WordList})
FOREACH(word ${WordList})
PRINT_MESSAGE(9 word ${word})
IF(${word} MATCHES ${RegexAbsoluteDir})
PRINT_MESSAGE(9 word ${word} matches ${RegexAbsoluteDir})
SET(DirList ${DirList} ${word})
ELSE(${word} MATCHES ${RegexAbsoluteDir})
PRINT_MESSAGE(9 word ${word} does not match ${RegexAbsoluteDir})
SET(DirList ${DirList} ${${ProjectName}_SOURCE_DIR}/${word})
ENDIF(${word} MATCHES ${RegexAbsoluteDir})
PRINT_MESSAGE(9 DirList ${DirList})
ENDFOREACH(word)
With Cmake 2.4.2 I got this output:
-- WordList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include does not
match ^([a-zA-Z][:])?[/\]
-- DirList
D:/Workspace/EDA/1.1/Packages/EDA_Interface/D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
With Cmake 2.0.6 I got:
-- WordList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include matches
^([a-zA-Z][:])?[/\]
-- DirList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
So, is this:
a) a bug ?
b) a fixed bug ?
If b), how should I modify my RegEx expression to get the desired result?
I have to work with the Cmake book for version 1.8 for now.
+-+-+- Email Confidentiality Footer +-+-+-
Privileged/Confidential Information may be contained in this message. If you
are not the addressee indicated in this message (or responsible for delivery of
the message to such person), you may not print, retain, copy nor disseminate
this message or any part of it to anyone and you should notify the sender by
reply email and destroy this message. Neglecting this clause could be a breach
of confidence. Please advise immediately if you or your employer does not
consent to Internet email for messages of this kind. Opinions, conclusions and
other information in this message that are not related to the official business
of my firm shall be understood as neither given nor endorsed by it.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] ExceptionHandling in VC8
Hello CMake users, I have noticed that the ExceptionHandling flag is not fully handled for VC8 projects. Namely, in VC7 this option could only be set to TRUE or FALSE. In VC8, we have the following options: Enable C++ exceptions : No - ExceptionHandling=0 Yes (/EHsc) - ExceptionHandling=1 Yes with SEH Exceptions (/EHa) - ExceptionHandling=2 The /EHa option is not handled by the generator and ends up in the AdditionalOptions line. This results for us in a warning (/EHsc replaced with /EHa) for every file we compile in our projects. It would be nice to have this option fully supported by CMake, especially since VC8 seems to become the new IDE of choice for Windows C++ development. Cheers, Laurentiu -- Laurentiu Nicolae Senior Software Engineer Quintiq Tel: +31 (0)73 691 07 39 Fax: +31 (0)73 691 07 54 www.quintiq.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest Question
At 04:51 PM 6/29/2006, Scott Amort wrote: William A. Hoffman wrote: make test should do the trick. You can also run ctest directly in the build tree. What you have should work. You might have to move the ENABLE_TESTING to the top of the project. Also you can look for the DartTesting. You can look for this file in your build tree and make sure it looks good: DartTestfile.txt Thanks Bill - I just needed to move ENABLE_TESTING up to the project root. Works now! However, it does compile the testing executables during the `make' command, and only runs them during the `make test'. If I make a change to one of the tests, I have to run `make' again, then `make test'... `make test' alone doesn't see that changes were made to the sources. Certainly only a minor complaint, but is there a way to restrict the compiling/link/executing of tests to the `make test' command? You may want to look at the ctest --build-and-test option. We use it in cmake itself. It will run cmake and do a build on a test that is not include in the parent build tree. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
I have a similar problem, except that using ADD_DEPENDENCIES to make the library with generated files a dependency of the targets that use it, causes the target libraries to include a copy of the dependent library when built as static libraries with VC71 (this is a long standing (mis)feature of visual studio). Since my generated library is large, the resulting build ends up being huge. Anyway, strictly speaking the (non-generated) targets only depend on the generated header files to compile. (For linking it will be handled correctly anyway via TARGET_LINK_LIBRARIES.) Looking at a make-based build it seems that if the generated header files exist, they are included in the dependencies of the source files using them, however in a clean build they don't exist yet, so aren't listed as dependencies. Since the generated header files have the GENERATED property set to true would it be possible for the dependency scan to include these files as dependencies even though they don't yet exist? It would then correctly go an generate the header files before compiling files that include them. Mike David Somers wrote: In a project I'm workking on I use makeheaders (http://www.cvstrac.org/cvstrac/dir?d=cvstrac) to automagically generate the h files for my c files. I'm using ADD_CUSTOM_TARGET to generate the headers, and some ADD_DEPENDENCIES magic to ensure they're generated before the code is compiled. All works quite well. However, as the cmake wiki says Note that generated headers can often cause unnecessary rebuilds and should be avoided if possible. And I've run into this problem :-( I have a library that depends on an application being done first (so that the library can pull in some of the headers that are generated when the app is made). Using ADD_DEPENDENCIES this is working automagically, but the problem I've hit is that the library has rebuild problems (i.e. it make will rebuilt it even when everything in it is up-to-date). Is there some way to 'persuade' cmake that in my library when foo.c does #include bar.h that it shouldn't add bar.h into the dependencies (because I've manually taken care of that elsewhere)? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] out-of-source build and generated files
Alexander Neundorf wrote:
If you generate files using ADD_CUSTOM_COMMAND(), you should always use full
paths for the generated files, i.e.
${CMAKE_CURRENT_BINARY_DIR}/generatedsource.cpp , both in the
ADD_CUSTOM_COMMAND() and in the list of source files.
Perfect... that did it. Thanks Alexander!
Best,
Scott
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest Question
William A. Hoffman wrote: You may want to look at the ctest --build-and-test option. We use it in cmake itself. It will run cmake and do a build on a test that is not include in the parent build tree. Hi Bill, I will look into this. Thanks again for your assistance! Best, Scott ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
At 05:58 PM 6/29/2006, David Somers wrote: In a project I'm workking on I use makeheaders (http://www.cvstrac.org/cvstrac/dir?d=cvstrac) to automagically generate the h files for my c files. I'm using ADD_CUSTOM_TARGET to generate the headers, and some ADD_DEPENDENCIES magic to ensure they're generated before the code is compiled. All works quite well. However, as the cmake wiki says Note that generated headers can often cause unnecessary rebuilds and should be avoided if possible. And I've run into this problem :-( I have a library that depends on an application being done first (so that the library can pull in some of the headers that are generated when the app is made). Using ADD_DEPENDENCIES this is working automagically, but the problem I've hit is that the library has rebuild problems (i.e. it make will rebuilt it even when everything in it is up-to-date). Why would make do that? Are you changing the generated .h files each run? Is there some way to 'persuade' cmake that in my library when foo.c does #include bar.h that it shouldn't add bar.h into the dependencies (because I've manually taken care of that elsewhere)? I am not sure I understand why you would want to do this. If the .h file has changed, you should rebuild any .c file that includes it. You might be able to use INCLUDE_REGULAR_EXPRESSION to make cmake skip some files. -- David Somers ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
On Friday 30 June 2006 17:41, you wrote: Why would make do that? Are you changing the generated .h files each run? Dammit! I was accidentally changing a file... doing cp instead of cp -p. G. Is there some way to 'persuade' cmake that in my library when foo.c does #include bar.h that it shouldn't add bar.h into the dependencies (because I've manually taken care of that elsewhere)? I am not sure I understand why you would want to do this. If the .h file has changed, you should rebuild any .c file that includes it. You might be able to use INCLUDE_REGULAR_EXPRESSION to make cmake skip some files. I had a situation where a tool would always regenerate a h file... I fudge the issue now by caching the file and only replace it if diff says the file really is different (opposed to just being newer). BTW, one hiccup I still have is this: for the COMMENT, how can I get it to print out the $ character? Thanks, David Somers typographer/programmer/whatever ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
At 12:26 PM 6/30/2006, David Somers wrote: BTW, one hiccup I still have is this: for the COMMENT, how can I get it to print out the $ character? \$ should work. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Regex changes between cmake 2.0.6 and 2.4.2 ??
Kris Dekeyser wrote:
Hi,
I was running my build macros in the latest CMake (2.4.2) and encountered very strange errors. With some debug printing I discovered that the new CMake version behaves differently regarding RegEx testing compared to the version 2.0.6 that we currently use.
This is a summary of what we do:
SET(RegexAbsoluteDir ^([a-zA-Z][:])?[/])
#--- Make directories absolute
SET(DirList)
PRINT_MESSAGE(9 WordList ${WordList})
FOREACH(word ${WordList})
PRINT_MESSAGE(9 word ${word})
IF(${word} MATCHES ${RegexAbsoluteDir})
PRINT_MESSAGE(9 word ${word} matches ${RegexAbsoluteDir})
SET(DirList ${DirList} ${word})
ELSE(${word} MATCHES ${RegexAbsoluteDir})
PRINT_MESSAGE(9 word ${word} does not match ${RegexAbsoluteDir})
SET(DirList ${DirList} ${${ProjectName}_SOURCE_DIR}/${word})
ENDIF(${word} MATCHES ${RegexAbsoluteDir})
PRINT_MESSAGE(9 DirList ${DirList})
ENDFOREACH(word)
With Cmake 2.4.2 I got this output:
-- WordList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include does not
match ^([a-zA-Z][:])?[/\]
-- DirList
D:/Workspace/EDA/1.1/Packages/EDA_Interface/D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
With Cmake 2.0.6 I got:
-- WordList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
-- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include matches
^([a-zA-Z][:])?[/\]
-- DirList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include
I just ran your example with 2.4.2 and got the latter output.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] subdirectories INSTALL(FILES subdir/foo.h ...)
Jan Woetzel wrote: Hi, I expected INSTALL(FILES subdir/foo.h DESTINATION include ) to install foo.h into include/subdir but it installs into: include Thus the subdirectory structure is lost. (1) This is a bug or am I missing something ? It works if I put the approppritae DESTINATION into each subdirectories CMakeLists.txt it works. But I want to use a globbing expression to install all headers keeping their subdirectory structure to avoid forgetting to ad dthem. I'm using Cmake 2.4.2 on Windows (with MSVS 7.1 generator). This is the expected behavior. The FILES option is meant to list the exact files that should be installed to the given destination regardless of source location. You can probably do what you want in CMake code with a combination of FILE(GLOB) and IF(IS_DIRECTORY). What is missing is an INSTALL(DIRECTORY ...) option. There is a feature request already in the bug tracker for this but it has not yet been implemented. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ExceptionHandling in VC8
Laurentiu Nicolae wrote: Hello CMake users, I have noticed that the ExceptionHandling flag is not fully handled for VC8 projects. Namely, in VC7 this option could only be set to TRUE or FALSE. In VC8, we have the following options: Enable C++ exceptions : No - ExceptionHandling=0 Yes (/EHsc) - ExceptionHandling=1 Yes with SEH Exceptions (/EHa) - ExceptionHandling=2 The /EHa option is not handled by the generator and ends up in the AdditionalOptions line. This results for us in a warning (/EHsc replaced with /EHa) for every file we compile in our projects. It would be nice to have this option fully supported by CMake, especially since VC8 seems to become the new IDE of choice for Windows C++ development. There is a table in the generator used to map command line options to GUI settings in the generated project files. The /EHa option is missing from this table. You can submit a bug report here: http://www.cmake.org/Bug -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] subdirectories INSTALL(FILES subdir/foo.h ...)
Brad King wrote: INSTALL(FILES subdir/foo.h DESTINATION include ) This is the expected behavior. ...You can probably do what you want in CMake code with a combination of FILE(GLOB) and IF(IS_DIRECTORY). Thanks for the information. I will write a macro to emulate this with GET_FILENAME_COMPONENT(... PATH) to do the job. Jan. -- Dipl.-Ing. Jan Woetzel -- University of Kiel Institute of Computer Science and Applied Mathematics Hermann-Rodewald-Str. 3 [room 310] 24098 Kiel/Germany -- Phone +49-431-880-4477 Fax +49-431-880-4054 Mob. +49-179-2937346 -- Url www.mip.informatik.uni-kiel.de/~jw Email [EMAIL PROTECTED] ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ExceptionHandling in VC8
At 01:31 PM 6/30/2006, Brad King wrote: Laurentiu Nicolae wrote: Hello CMake users, I have noticed that the ExceptionHandling flag is not fully handled for VC8 projects. Namely, in VC7 this option could only be set to TRUE or FALSE. In VC8, we have the following options: Enable C++ exceptions : No - ExceptionHandling=0 Yes (/EHsc) - ExceptionHandling=1 Yes with SEH Exceptions (/EHa) - ExceptionHandling=2 The /EHa option is not handled by the generator and ends up in the AdditionalOptions line. This results for us in a warning (/EHsc replaced with /EHa) for every file we compile in our projects. It would be nice to have this option fully supported by CMake, especially since VC8 seems to become the new IDE of choice for Windows C++ development. There is a table in the generator used to map command line options to GUI settings in the generated project files. The /EHa option is missing from this table. You can submit a bug report here: http://www.cmake.org/Bug Don't bother, I just commited a fix. Checking for path: /cvsroot/CMake/CMake/Source Unrestricted user: hoffman /cvsroot/CMake/CMake/Source/cmLocalVisualStudio7Generator.cxx,v -- cmLocalVis ualStudio7Generator.cxx new revision: 1.139; previous revision: 1.138 Please try cvs cmake if you get a chance. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] subdirectories INSTALL(FILES subdir/foo.h ...)
Brad King wrote:
You can probably do what you want in CMake code with a combination of
FILE(GLOB) and IF(IS_DIRECTORY).
INSTALL(DIRECTORY ...) option. There is a feature request already in
the bug tracker for this but it has not yet been implemented.
For the records - this works:
FILE(GLOB_RECURSE BIAS_HEADER RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} *.h* )
FOREACH(VAR ${BIAS_HEADER})
# drop headers from Example dir and .in files
IF (${VAR} MATCHES .*Example.*|.*\\.in)
REMOVE(BIAS_HEADER ${VAR})
ELSE (${VAR} MATCHES .*Example.*|.*\\.in)
# extract directoy for DESTINATION subdir tree until
INSTALL(DIRECTORY exists)
GET_FILENAME_COMPONENT(DIR ${VAR} PATH)
INSTALL(FILES ${BIAS_HEADER} DESTINATION include/BIAS/${DIR} )
ENDIF(${VAR} MATCHES .*Example.*|.*\\.in)
ENDFOREACH(VAR)
Jan.
--
Dipl.-Ing. Jan Woetzel
--
University of Kiel
Institute of Computer Science and Applied Mathematics
Hermann-Rodewald-Str. 3 [room 310]
24098 Kiel/Germany
--
Phone +49-431-880-4477
Fax +49-431-880-4054
Mob. +49-179-2937346
--
Url www.mip.informatik.uni-kiel.de/~jw
Email [EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: fixed - Re: [CMake] Forcing C++: What Causes VC Warning D4025 : overriding /TP with /TC
I reported the same bug (05.06.2006 21:33), too. Will already fixed it in CVS. BTW, I've been looking in the Bug Tracker, and I can't find this. I don't see a 'by date reported' search, nor a 'by submittor' search. What would be the best way to find what's already been written on this subject in the Bug Tracker? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: fixed - Re: [CMake] Forcing C++: What Causes VC Warning D4025 : overriding /TP with /TC
At 02:46 PM 6/30/2006, Steve Johns wrote: I reported the same bug (05.06.2006 21:33), too. Will already fixed it in CVS. BTW, I've been looking in the Bug Tracker, and I can't find this. I don't see a 'by date reported' search, nor a 'by submittor' search. What would be the best way to find what's already been written on this subject in the Bug Tracker? This problem should be fixed in CVS. It no longer adds both /TP and /TC. Please try cvs before reporting a new bug, or opening an old one. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
On Friday 30 June 2006 19:07, William A. Hoffman wrote: At 12:26 PM 6/30/2006, David Somers wrote: BTW, one hiccup I still have is this: for the COMMENT, how can I get it to print out the $ character? \$ should work. That's what I would have expected too... but it doesn't :-( I'm doing this from within a MACRO ... so perhaps there is something else I need to do? -- David Somers ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
David Somers wrote:
On Friday 30 June 2006 19:07, William A. Hoffman wrote:
At 12:26 PM 6/30/2006, David Somers wrote:
BTW, one hiccup I still have is this: for the COMMENT, how can I get it to
print out the $ character?
\$ should work.
That's what I would have expected too... but it doesn't :-(
I'm doing this from within a MACRO ... so perhaps there is something else I
need to do?
The COMMENT is placed directly in the makefile as
@echo COMMENT
In order to get make to echo a dollar you need this:
@echo \$$
Try this:
SET(COMMENT_DOLLAR \\$$)
ADD_CUSTOM_COMMAND(
...
COMMENT Here is a dollar: ${COMMENT_DOLLAR} !!!
)
Other generators will also put the comment literally in the build file,
and may require different escaping, so you may need to set
COMMENT_DOLLAR differently in those cases.
Really it should be CMake's job to figure out how to get the comment to
display as the user specified. You can submit a bug report here:
http://www.cmake.org/Bug
but it may not get attention for a while as this is pretty obscure IMHO.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: fixed - Re: [CMake] Forcing C++: What Causes VC Warning D4025 : overriding /TP with /TC
Bill,
Thanks for responding.
This problem should be fixed in CVS. It no longer adds both /TP and /TC.
Please try cvs before reporting a new bug, or opening an old one.
OK, that's what I did, hence my earlier message (quoted below). Since that
one got no replies, I figured I was being subtly encouraged to check out the
history/status of the bug/resolution via the Bug Tracker.
So, at this point, protocol-wise, I'm confused about the best and proper way
to
a) investigate the status/resolution of a previously reported bug
b) understand where and how a fix was made, both generally and for this
specific bug
c) understand when and why patch releases are prepared, or not
Maybe I've created a hairball of questions by this point, which wasn't my
intent.
I want to use the available resources efficiently and curteously - I'm
asking questions to understand how to do so.
I would welcome guidance on any/all of a) - c), in whole or in part.
Thanks!
- Steve
Earlier post:
Thank you for this info. I'm now looking at something that seems
relevant,
but this look has raised more questions in my mind.
I am currently running the binary distro of 2-4-2
Inside:
cmLocalVisualStudio7Generator.cxx
Revision: 1.125.2.3, Sun May 14 19:22:42 2006 UTC (6 weeks, 4 days ago) by
hoffman
Branch: CMake-2-4
CVS Tags: CMake-2-4-2
Changes since 1.125.2.2: +107 -62 lines
I find:
// if the source file does not match the linker language
// then force c or c++
if(linkLanguage lang strcmp(lang, linkLanguage) != 0)
{
if(strcmp(lang, CXX) == 0)
{
// force a C++ file type
compileFlags += /TP ;
}
else if(strcmp(lang, C) == 0)
{
// force to c
compileFlags += /TC ;
}
}
If I'm reading this right (?), this is the CAUSE of the problem - i.e.
this
is where the trailing /TC gets added at the end of the build command,
when lang == C, which is when the file has a .c extension. Is this
right
so far?
then I find, in this later version, ( later than 2-4-2, meaning it's not
in
my CMake executable, yes?) :
cmLocalVisualStudio7Generator.cxx
Revision 1.135 - (view) (download) (as text) (annotate) - [select for
diffs]
Tue Jun 6 16:01:23 2006 UTC (3 weeks, 2 days ago) by hoffman
Branch: MAIN
ENH: fix /TP for c code
Is this the fix you refer to?
I looked at the diff for these two versions, and see that 1.135 adds code
down around line 1167 dealing with flags in some way that I can't quickly
decipher, but which has no immediately recognizable reference to /TC or
/TP .
If this is the fix, and it works, I'd be interested to understand how it
works.
If this is not the fix, I'm sorry for getting it wrong, and I'd welcome a
pointer to the correct revision.
Finally, it seems that binary distros are prepared relatively
infrequently.
Is getting this:
SET(CMAKE_C_COMPILER ${CMAKE_CXX_COMPILER})
SET_TARGET_PROPERITES( tgt PROPERTIES LINKER_LANGUAGE CXX)
to work as intended in these circumstances not judged important enough to
warrant a 2-4-3 build?
It would be helpful, if possible, to be able to refer my development
partner(s) to a binary distro of CMake that handles this situation.
If I have to bite the bullet and start compiling CMake's own source code,
and getting partner(s) to do same, I imagine we can and will, but if
generating a 2-4-3 binary at home base is not hard, perhaps it would be
worthwhile and save some people from extra work and possible issues in the
field.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
