Re: [CMake] Produce only an object file (*.o) from a CMake build target
On 01/24/2011 06:37 PM, Helseth, Nicholas H wrote:
> I'm trying to build an object file using CMake, but I can't seem to get CMake
> to build something other than a complete executable. I'm basically looking
> for the result of the following compilation (the result will be loaded on a
> VxWorks target and linked then-it needs to be a *.o because of the way our
> build system works):
> $(CC) $(CFLAGS) $(INC_DIRS) -c src/object.c
> I've tried changing the OUTPUT_NAME property of the target, but that doesn't
> seem to help, either.
> I think I could work around this by using a custom command, but that seems
> like I'm also working around the nice things that CMake provides.
> Thanks for your help!
Look at the following ${CMAKE_SOURCE_DIR}/cpo script:
#!/bin/sh
d=$1; shift
while [ "$1" != "--" ]; do
cp $1 $d/$(basename $1); shift
done
Now, look at the following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CPO C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
ADD_LIBRARY(f SHARED f.c)
SET_TARGET_PROPERTIES(f PROPERTIES RULE_LAUNCH_LINK
"${CMAKE_SOURCE_DIR}/cpo ${CMAKE_BINARY_DIR} --"
)
The launch script "cpo" makes the target "f" produce object files in
the directory passed in as the first parameter instead of a library;
everything else should be business as usual. The key is the script's
access to the placeholder, so it can operate on the object
files while the actual link command after the "--" is ignored. That
way, you can use all of CMake's capabilities for the compilation and
intercept right before linking takes place. IMO, that's a quite clean
solution which should be easily adaptable to your needs; the downside
is that the use of RULE_LAUNCH_LINK is limited to Makefile generators.
Regards,
Michael
___
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
Re: [CMake] cmake with LaTeX [UseLATEX.cmake]
Hi Daniel,
Thanks for the reply!
On Tue, Jan 25, 2011 at 16:15, Daniel Pfeifer wrote:
> Am Dienstag, den 25.01.2011, 15:41 +0900 schrieb Raymond Wan:
>> Everything is fine except that pdflatex
>> doesn't seem to work with images well on my system... That's of
>> course my system [or my :-) ] fault, though.
>
> Do you use the IMAGE_DIRS or IMAGES parameters? UseLATEX.cmake should
> then convert all images to the right format. Maybe check you imagemagick
> installation.
Actually, neither. I couldn't get them to work and went to plan B.
:-) I have a directory structure like:
top-level/
+latex/
+latex/build/
+figures/
So, my figures are in figures/. I thought this would do:
IMAGE_DIRS "${CMAKE_CURRENT_SOURCE_DIR}/../figures/"
but it wasn't working for me I also tried IMAGES and that didn't work
as well. I didn't pursue this further as I got:
\graphicspath{{@CMAKE_CURRENT_SOURCE_DIR@/../figures/}}
in the source LaTeX file to work and all my figures are in EPS format
anyway. I will take a look at my imagemagick installation; but it
might also be that the figures aren't being located.
>> ... Is there something I can do
>> in my CMakeLists.txt file to ensure that it is the default target (and
>> not "pdf" or any of the others) when I type "make".
>
> Sure, there is the DEFAULT_PDF option. Have a look at section '3.3
> Create a PDF by Default' in the manual.
Yes, I've enabled that but I don't think that allows me to choose the
"pdf" target over the "safepdf" target. Or is there something I'm
missing with this option?
Thank you!
Ray
___
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
Re: [CMake] cmake with LaTeX [UseLATEX.cmake]
Hi Daniel, On Tue, Jan 25, 2011 at 16:15, Daniel Pfeifer wrote: > Am Dienstag, den 25.01.2011, 15:41 +0900 schrieb Raymond Wan: >> ... Is there something I can do >> in my CMakeLists.txt file to ensure that it is the default target (and >> not "pdf" or any of the others) when I type "make". > > Sure, there is the DEFAULT_PDF option. Have a look at section '3.3 > Create a PDF by Default' in the manual. Thank you again for your help. I gathered my courage for the week :-) and decided to look at the source. Based on my limited knowledge of cmake, it seems that DEFAULT_PDF favors the pdflatex route. Which is of course not unreasonable if you're unlike me and have a working Imagemagick. ;-) I changed it a bit and added a "DEFAULT_SAFEPDF" option and it seems to work. I will ask the original author to see if this change is of interest to him. Thanks again for your reply -- it did lead me to the right direction! Ray ___ 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
[CMake] add_custom_command and generated true
Recently, I learned that ADD_CUSTOM_COMMAND generated the property
GENERATED TRUE for the generated file.
Somehow I have trouble in this situation:
In a top level CMakeLists file a source file, blue.c, is generated. This
file should be used in a subdirectory with its own CMakeLists file.
Running CMake generates the message: "cannot find blue.c etc..."
Okay, the information, that this is a generated sourcefile is, maybe,
lost on the transition to the subdirectory.
So, I inserted in the CMakeLists file of subdirectory the line:
SET_SOURCE_FILES_PROPERTIES(blue.c PROPERTIES GENERATED TRUE)
which generates the make message
No rule to build target subdirectory/blue.c
I changed the inserted line (see above) to...
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/blue.c
PROPERTIES GENERATED TRUE)
... which is okay.
=> Two question
- Is it general true, that properties are lost on transition to a
subdirectory?
- In which cases is it absolute necessary to work with absolute paths
and SET_SOURCE_FILES?
In the appendix is a small example (Unix only)
Greetings
Micha
CMakeQuest.tar.gz
Description: application/compressed-tar
___
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
Re: [CMake] Cannot run/debug cmake project with MSVC 2010 which works well in Linux
On Mon, Jan 24, 2011 at 10:03 PM, Srimal Jayawardena wrote: > Hi > > Thanks for the advise. You're welcome. Please include the CMake mailing list on all your replies so that: (1) others may jump in and help in case I can't reply to a particular email in a timely manner and (2) others may benefit from the archived replies. (Thanks...) > > I've done > >> Right click on "textureBackProjection" and choose "Set as StartUp >> Project" -- after that, F5 will launch the executable for that >> project. > > > But I get these errors. > > > 'textureBackprojection.exe': Loaded 'C:\Documents and > Settings\Administrator\Desktop\maptexture\buildwin32\Debug\textureBackprojection.exe', > Symbols loaded. > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded > 'C:\WINDOWS\system32\kernel32.dll', Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system\glut32.dll', > Binary was not built with debug information. > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\user32.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\winmm.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded > 'C:\WINDOWS\system32\advapi32.dll', Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\secur32.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\glu32.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded > 'C:\WINDOWS\system32\opengl32.dll', Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\ddraw.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded > 'C:\WINDOWS\system32\dciman32.dll', Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded > 'C:\WINDOWS\system32\msvcr100d.dll', Symbols loaded. > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\imm32.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\lpk.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\usp10.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\Program Files\Sophos\Sophos > Anti-Virus\sophos_detoured.dll', Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\psapi.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\msctf.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\version.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Unloaded 'C:\WINDOWS\system32\version.dll' > 'textureBackprojection.exe': Loaded > 'C:\WINDOWS\system32\msctfime.ime', Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded > 'C:\WINDOWS\system32\atioglxx.dll', Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\version.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\ws2_32.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\ws2help.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Loaded 'C:\WINDOWS\system32\mcd32.dll', > Cannot find or open the PDB file > 'textureBackprojection.exe': Unloaded 'C:\WINDOWS\system32\mcd32.dll' These "Cannot find or open the PDB file" messages are just informational messages that tell you you don't have the debugging files for Windows itself installed. This is normal -- most people see this. You'll get used to this after a little while. (You could have figured this one out pretty easily just googling for the phrase "Cannot find or open the PDB file") > The program '[4940] textureBackprojection.exe: Native' has exited with > code 1 (0x1). This line means your "main" returned "1" (or some code you called did an "exit(1);" ... ) > > > > (Btw can we set the startup project automatically by setting an > option in the CMakeList.txt file?) No, net yet. People have asked for this feature, but we have not figured out a good way to do it yet. > > Thanks in advance > You're welcome. Cheers, David > Srimal > > On Tue, Jan 25, 2011 at 1:18 PM, David Cole wrote: >> Right click on "textureBackProjection" and choose "Set as StartUp >> Project" -- after that, F5 will launch the executable for that
Re: [CMake] Restrictions on where a binary can be put?
On 01/21/2011 08:47 AM, Andreas Pakulat wrote: > On 21.01.11 01:37:41, Michael Hertling wrote: >> So, what's your conclusion in this matter? Should the behavior in >> question be considered as a bug or is it alright? IMO, such a subtle >> side effect of a read operation on a subsequent write operation is at >> least highly surprising. Besides, does one have to take this phenomenon >> into account elsewhere, i.e. when saying >> >> GET_TARGET_PROPERTY( X) >> ... >> SET_TARGET_PROPERTIES( PROPERTIES Y ...) >> >> with X!=LOCATION and Y!=RUNTIME_OUTPUT_DIRECTORY, is it assured that >> the latter command works as expected? Are directory or source files >> properties possibly affected, too? > > Check the bugreport I mentioned further up in the thread. The docs have > been expanded to mention this problem with LOCATION and > RUNTIME_OUTPUT_DIRECTORY. As far as I understood Brad in the report its > unique to those properties defining where a target ends up on disk (and > how). And indeed (as he said also) changing the output directory _after_ > querying it (via LOCATION) hints towards a bug in your cmake code, after > all whatever you did with LOCATION is void if you change the output > directory again and you'd have to re-run that code. Thanks for this hint, Andreas; I really should have taken a look at the bug tracker the day after you filed the report. ;) After one-and-a-half thought about that issue, it is rather obvious that changing a target's location on disk after querying the location results in strange effects one way or another. So, with the improved documentation and the already obsolete LOCATION property, it's certainly alright now. Regards, Michael ___ 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
Re: [CMake] Restrictions on where a binary can be put?
On 01/21/2011 04:41 PM, Alexander Neundorf wrote: > On Friday 21 January 2011, Michael Hertling wrote: >> On 01/20/2011 07:01 PM, Alexander Neundorf wrote: >>> On Sunday 09 January 2011, Michael Hertling wrote: > ... > I don't really understand why you want to get the LOCATION from your > target, anyway, the get_target_property works fine if you use > set_target_properties before it. [...] ...but SET_TARGET_PROPERTIES() doesn't work fine if it's used after GET_TARGET_PROPERTY(), even if both operate on different properties. >>> >>> Well, they are not completely different. >>> If I remember correctly, the LOCATION property is "calculcated" when you >>> query it. I think it changes some internal variables. Apparently to a >>> state where setting the target property afterwards doesn't have the >>> desired effect anymore :-/ >> >> So, what's your conclusion in this matter? Should the behavior in >> question be considered as a bug or is it alright? IMO, such a subtle > > IMO looks quite obvious like a bug. I just wanted to say that there is some > connection between the properties. While this issue with the LOCATION/LOCATION_ properties has been clarified in #11671 in the meantime, I wonder whether there're more interconnections of that kind among other properties, just to be mindful of them when they emerge. So, does anybody have some information on this? Regards, Michael ___ 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
Re: [CMake] Cannot run/debug cmake project with MSVC 2010 which works well in Linux
> > > > > > > > (Btw can we set the startup project automatically by setting an > > option in the CMakeList.txt file?) > > No, net yet. People have asked for this feature, but we have not > figured out a good way to do it yet. > > You might consider using my CreateLaunchers.cmake script, which can set the debugging/run options of the ALL_BUILD target to achieve the same result. https://github.com/rpavlik/cmake-modules Ryan -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com Internal VRAC/HCI Site: http://tinyurl.com/rpavlik ___ 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
[CMake] CMake 2.8.3 with VC2010 - CHECK_FUNCTION_EXISTS failed
Hi,
When I use the following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED (VERSION 2.8)
INCLUDE(${CMAKE_ROOT}/Modules/CheckFunctionExists.cmake)
CHECK_FUNCTION_EXISTS(log HAVE_LOG)
CHECK_FUNCTION_EXISTS(exp HAVE_EXP)
E:\var>cmake -G "NMake Makefiles"
-- The C compiler identification is MSVC
-- The CXX compiler identification is MSVC
-- Check for CL compiler version
-- Check for CL compiler version - 1600
-- Check if this is a free VC compiler
-- Check if this is a free VC compiler - no
-- Check for working C compiler: E:/usr/vs2010/VC/bin/cl.exe
-- Check for working C compiler: E:/usr/vs2010/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: E:/usr/vs2010/VC/bin/cl.exe
-- Check for working CXX compiler: E:/usr/vs2010/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for log
-- Looking for log - not found
-- Looking for exp
-- Looking for exp - not found
-- Configuring done
-- Generating done
-- Build files have been written to: E:/var
>From the CMakeError.log file:
...
Building C object CMakeFiles/cmTryCompileExec.dir/CheckFunctionExists.c.obj
E:\usr\vs2010\VC\bin\cl.exe
@C:\DOCUME~1\DONGSH~1\LOCALS~1\Temp\nm506.tmp
cl : Command line warning D9025 : overriding '/MD' with '/MDd'
cl : Command line warning D9025 : overriding '/O2' with '/Od'
CheckFunctionExists.c
E:\usr\CMake-2.8\share\cmake-2.8\Modules\CheckFunctionExists.c(21) : fatal
error C1189: #error : "CHECK_FUNCTION_EXISTS has to specify the function"
...
But I can success compile and link with the following command line:
E:\var>cl /DCHECK_FUNCTION_EXISTS=log
E:\usr\CMake-2.8\share\cmake-2.8\Modules\CheckFunctionExists.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for
80x86
Copyright (C) Microsoft Corporation. All rights reserved.
CheckFunctionExists.c
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
/out:CheckFunctionExists.exe
CheckFunctionExists.obj
>From the page
http://www.cmake.org/Wiki/CMake_FAQ#Is_there_an_option_to_produce_more_.27verbose.27_compiling.3F
but when I set CMAKE_START_TEMP_FILE and CMAKE_END_TEMP_FILE to "" ,
CMakeError.log still include such lines:
E:\usr\vs2010\VC\bin\cl.exe @C:\DOCUME~1\DONGSH~1\LOCALS~1\Temp\nm506.tmp
Then I can not check more details.
Thanks for some help.
--
Dongsheng
___
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
Re: [CMake] add_custom_command and generated true
On 01/25/2011 10:17 AM, Micha Renner wrote:
> Recently, I learned that ADD_CUSTOM_COMMAND generated the property
> GENERATED TRUE for the generated file.
>
> Somehow I have trouble in this situation:
>
> In a top level CMakeLists file a source file, blue.c, is generated. This
> file should be used in a subdirectory with its own CMakeLists file.
>
> Running CMake generates the message: "cannot find blue.c etc..."
>
> Okay, the information, that this is a generated sourcefile is, maybe,
> lost on the transition to the subdirectory.
The documentation of SET_SOURCE_FILES_PROPERTIES() states
"Source file properties are visible only to targets added in the same
directory (CMakeLists.txt)."
and GENERATED is a source file property, so it's not amazing that the
subdirectory's CMakeLists.txt doesn't recognize blue.c as generated,
even if the property is imposed by ADD_CUSTOM_COMMAND(OUTPUT ...).
> So, I inserted in the CMakeLists file of subdirectory the line:
> SET_SOURCE_FILES_PROPERTIES(blue.c PROPERTIES GENERATED TRUE)
> which generates the make message
> No rule to build target subdirectory/blue.c
Explicitly setting the GENERATED property here quiets CMake, but the
subdirectory's Makefile won't have a rule to generate blue.c because
the custom command is defined in the top-level CMakeLists.txt; from
the documentation of ADD_CUSTOM_COMMAND():
"A target created in the same directory (CMakeLists.txt file)
that specifies any output of the custom command as a source file
is given a rule to generate the file using the command at build time."
So, the build will fail with the mentioned error message from make.
> I changed the inserted line (see above) to...
> SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/blue.c
>PROPERTIES GENERATED TRUE)
> ... which is okay.
AFAICS from your example, this works by accident: The custom target is
processed before make descends to the subdirectory, so blue.c already
exists when the cTest target gets built, and CMake is happy because
blue.c is marked as GENERATED in that *directory's* CMakeLists.txt.
Remove the ALL flag from the ADD_CUSTOM_TARGET() command, and you
will probably see your example fail, regardless if and how the
GENERATED property is set.
> => Two question
>
> - Is it general true, that properties are lost on transition to a
> subdirectory?
This is true for the source file properties and for some directory
properties like EXCLUDE_FROM_ALL; the latter is not inherited by sub-
directories, but the COMPILE_DEFINITIONS directory property, e.g., is.
> - In which cases is it absolute necessary to work with absolute paths
> and SET_SOURCE_FILES?
IMO, the rule of thumb is: Use absolute paths where the behavior
for relative paths is not specified or not appropriate. E.g.,
ADD_CUSTOM_COMMAND(OUTPUT blue.c ...)
will generate ${CMAKE_CURRENT_BINARY_DIR}/blue.c, but which directory
SET_SOURCE_FILES_PROPERTIES(blue.c PROPERTIES ...)
bases on? For the GENERATED property, CMAKE_CURRENT_BINARY_DIR would be
reasonable, but for the LANGUAGE property, CMAKE_CURRENT_SOURCE_DIR
might suit better. Thus, SET_SOURCE_FILES_PROPERTIES() should be
invoked with absolute paths only.
BTW, you shouldn't do in-source builds, and do not write to the source
directories; it's bad style, doesn't play nicely with version control
systems and might be the reason for some quite subtle problems.
Regards,
Michael
___
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
Re: [CMake] add_custom_command and generated true
Am Dienstag, den 25.01.2011, 15:34 +0100 schrieb Michael Hertling:
> On 01/25/2011 10:17 AM, Micha Renner wrote:
> > Recently, I learned that ADD_CUSTOM_COMMAND generated the property
> > GENERATED TRUE for the generated file.
> >
> > Somehow I have trouble in this situation:
> >
> > In a top level CMakeLists file a source file, blue.c, is generated. This
> > file should be used in a subdirectory with its own CMakeLists file.
> >
> > Running CMake generates the message: "cannot find blue.c etc..."
> >
> > Okay, the information, that this is a generated sourcefile is, maybe,
> > lost on the transition to the subdirectory.
>
> The documentation of SET_SOURCE_FILES_PROPERTIES() states
>
> "Source file properties are visible only to targets added in the same
> directory (CMakeLists.txt)."
>
> and GENERATED is a source file property, so it's not amazing that the
> subdirectory's CMakeLists.txt doesn't recognize blue.c as generated,
> even if the property is imposed by ADD_CUSTOM_COMMAND(OUTPUT ...).
>
> > So, I inserted in the CMakeLists file of subdirectory the line:
> > SET_SOURCE_FILES_PROPERTIES(blue.c PROPERTIES GENERATED TRUE)
> > which generates the make message
> > No rule to build target subdirectory/blue.c
>
> Explicitly setting the GENERATED property here quiets CMake, but the
> subdirectory's Makefile won't have a rule to generate blue.c because
> the custom command is defined in the top-level CMakeLists.txt; from
> the documentation of ADD_CUSTOM_COMMAND():
>
> "A target created in the same directory (CMakeLists.txt file)
> that specifies any output of the custom command as a source file
> is given a rule to generate the file using the command at build time."
>
> So, the build will fail with the mentioned error message from make.
>
> > I changed the inserted line (see above) to...
> > SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/blue.c
> > PROPERTIES GENERATED TRUE)
> > ... which is okay.
>
> AFAICS from your example, this works by accident: The custom target is
> processed before make descends to the subdirectory, so blue.c already
> exists when the cTest target gets built, and CMake is happy because
> blue.c is marked as GENERATED in that *directory's* CMakeLists.txt.
> Remove the ALL flag from the ADD_CUSTOM_TARGET() command, and you
> will probably see your example fail, regardless if and how the
> GENERATED property is set.
>
> > => Two question
> >
> > - Is it general true, that properties are lost on transition to a
> > subdirectory?
>
> This is true for the source file properties and for some directory
> properties like EXCLUDE_FROM_ALL; the latter is not inherited by sub-
> directories, but the COMPILE_DEFINITIONS directory property, e.g., is.
>
> > - In which cases is it absolute necessary to work with absolute paths
> > and SET_SOURCE_FILES?
>
> IMO, the rule of thumb is: Use absolute paths where the behavior
> for relative paths is not specified or not appropriate. E.g.,
>
> ADD_CUSTOM_COMMAND(OUTPUT blue.c ...)
>
> will generate ${CMAKE_CURRENT_BINARY_DIR}/blue.c, but which directory
>
> SET_SOURCE_FILES_PROPERTIES(blue.c PROPERTIES ...)
>
> bases on? For the GENERATED property, CMAKE_CURRENT_BINARY_DIR would be
> reasonable, but for the LANGUAGE property, CMAKE_CURRENT_SOURCE_DIR
> might suit better. Thus, SET_SOURCE_FILES_PROPERTIES() should be
> invoked with absolute paths only.
Thanks, these are understandable explanations. Very good.
>
> BTW, you shouldn't do in-source builds, and do not write to the source
> directories; it's bad style, doesn't play nicely with version control
> systems and might be the reason for some quite subtle problems.
I know, but sometimes you have a given structure, which you can't
change. The above example is the result of a move-over of glibmm. Here
many src-files are generated in-source and these files already exists.
If I install the CMake scripts, I could remove the generated source
files, but then I need a list of the generated files in my installation
script and this is want I don't want.
Greetings Micha
___
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
Re: [CMake] Improvements for cross-referencing in the documentation?
I use the following script to generate a QtAssistant based documentation set.
This allows quick searching of the docs and a more organized CMake
documentation package. Here is the bash script. Maybe some else will find it
useful also. I'll be the first to admit that I am not the best/most efficient
script writer but it does work.
# START SCRIPT
#!/bin/bash
# This is a shell script to generate a QtAssistant set of docs from the CMake
distribution.
#
# Couple of things to get you started with this file:function file
# All the files are generated in the /tmp directory. If you want them
somewhere else
# set the 'generationDir' variable
qtassistant="$QTDIR/bin/Assistant_adp.app/Contents/MacOS/assistant_adp"
CMAKE=`which cmake`
generationDir="/tmp/CMakeDocs"
assistantDir="${generationDir}/cmake_assistant_docs"
# remove any previous builds of the docs
rm -rf ${assistantDir}
mkdir -p ${assistantDir}
adpFile=${assistantDir}/CMakeDocs.adp
tmpHTMLFile="${generationDir}/temp.html"
tmpSortFile="${generationDir}/sorted.txt"
#-- Create a shell script to launch QtAssistant once everything is built
ShellScriptPath="/Users/mjackson/Library/ShellScripts"
echo "${QTDIR}/bin/Assistant_adp.app/Contents/MacOS/assistant_adp -profile
$generationDir/cmake_assistant_docs/CMakeDocs.adp" >
$ShellScriptPath/cmakedocs.sh
chmod ugo+rwx $ShellScriptPath/cmakedocs.sh
#css_sheet="http://www.kitware.com/kitware.css";
css_sheet="./cmake.css"
#
# Start the main index.html file that lists the major doc groups, Commands,
Modules, Variables
#
mainIndexFileName="index.html"
mainIndexFile=${assistantDir}/${mainIndexFileName}
echo "" > ${mainIndexFile}
echo ">
${mainIndexFile}
echo "\"http://www.w3.org/TR/html4/loose.dtd\";>" >> ${mainIndexFile}
echo "" >> ${mainIndexFile}
echo " "
>> ${mainIndexFile}
echo "CMake Documentation" >> ${mainIndexFile}
echo "" >>
${mainIndexFile}
echo "" >> ${mainIndexFile}
echo "" >> ${mainIndexFile}
echo "" >> ${mainIndexFile}
#
# Start the Qt adp file
#
echo "" > ${adpFile}
echo "" > ${adpFile}
echo "" >> ${adpFile}
echo " CMake Documentation" >> ${adpFile}
echo " CMake Docs" >> ${adpFile}
#echo " " >> ${adpFile}
echo " index.html" >> ${adpFile}
echo " About CMake Docs Viewer"
>> ${adpFile}
#echo " about.txt" >> ${adpFile}
#echo " ." >> ${adpFile}
echo " " >> ${adpFile}
echo "" >> ${adpFile}
echo "" >> ${adpFile}
#
# Function GenerateDocsForCommand This function will create all the
# individual html files, an index file and the proper section of the .adp file
# $1 The type of docs we are going to generate 'command' 'module' 'variable'
function GenerateDocsForCommand()
{
docDirName="cmake_${1}_docs"
docDir="${assistantDir}/${docDirName}"
mkdir ${docDir}
listFile="${generationDir}/list.txt"
${CMAKE} --help-${1}-list ${listFile}
echo "* Generating HTML files for command '${1}'"
#
# Start the Index File for this group of docs
#
indexFile=${docDir}/cmake_${1}_index.html
echo "" > ${indexFile}
echo ">
${indexFile}
echo "\"http://www.w3.org/TR/html4/loose.dtd\";>" >> ${indexFile}
echo "" >> ${indexFile}
echo "
" >> ${indexFile}
echo "CMake ${1} Index" >> ${indexFile}
echo ""
>> ${indexFile}
echo "" >> ${indexFile}
echo "" >> ${indexFile}
echo "" >> ${indexFile}
echo "All CMake Documentation" >>
${indexFile}
#
# Create a section in the .adp file
#
echo " " >>
${adpFile}
#
# Create a section in the top level index file
#
echo "CMake ${1}s" >>
${mainIndexFile}
#
# Generate all the individual documentation html files
#
rm $tmpSortFile
touch ${tmpSortFile}
i=0
exec 9<${listFile}
while read -u 9 line
do
if [[ ${i} -gt 0 ]]; then
echo "${line}" >> ${tmpSortFile}
fi
let i=i+1
done
exec 9<&-
# Now sort the file
echo "Sorting the List of ${1}"
sort ${tmpSortFile} --output=${listFile}
# Now read the file and get the docs for the command, variable etc.
i=0
exec 8<${listFile}
while read -u 8 line
do
#if [[ ${i} -gt 0 ]]; then
echo ${i}": ${line}"
# Seems that CMake only puts out the body portion
Re: [CMake] cmake with LaTeX [UseLATEX.cmake]
Looking at the source code, I believe it is assumed that the paths you give for
images are relative to the directory ADD_LATEX_DOCUMENT is called. If you make
it an absolute path, UseLATEX.cmake will look in the wrong directory for your
images, find none, and do no conversions. That would explain why you had to
point to your source directory and why pdflatex did not work if your images are
in eps format.
In summary, it should work if you use this as for IMAGE_DIRS
IMAGE_DIRS ../figures
and your graphics paths should be preserved relative to the source:
\graphicspath{../figures}
Note, however, if you are trying to do an in-source build with the directory
structure below, UseLATEX.cmake will probably do something screwy with the
figures output directory (that is, place it in top-level/latex/figures since
that is one level down from top-level/latex/figures).
-Ken
On 1/25/11 1:23 AM, "Raymond Wan" wrote:
Hi Daniel,
Thanks for the reply!
On Tue, Jan 25, 2011 at 16:15, Daniel Pfeifer wrote:
> Am Dienstag, den 25.01.2011, 15:41 +0900 schrieb Raymond Wan:
>> Everything is fine except that pdflatex
>> doesn't seem to work with images well on my system... That's of
>> course my system [or my :-) ] fault, though.
>
> Do you use the IMAGE_DIRS or IMAGES parameters? UseLATEX.cmake should
> then convert all images to the right format. Maybe check you imagemagick
> installation.
Actually, neither. I couldn't get them to work and went to plan B.
:-) I have a directory structure like:
top-level/
+latex/
+latex/build/
+figures/
So, my figures are in figures/. I thought this would do:
IMAGE_DIRS "${CMAKE_CURRENT_SOURCE_DIR}/../figures/"
but it wasn't working for me I also tried IMAGES and that didn't work
as well. I didn't pursue this further as I got:
\graphicspath{{@CMAKE_CURRENT_SOURCE_DIR@/../figures/}}
in the source LaTeX file to work and all my figures are in EPS format
anyway. I will take a look at my imagemagick installation; but it
might also be that the figures aren't being located.
>> ... Is there something I can do
>> in my CMakeLists.txt file to ensure that it is the default target (and
>> not "pdf" or any of the others) when I type "make".
>
> Sure, there is the DEFAULT_PDF option. Have a look at section '3.3
> Create a PDF by Default' in the manual.
Yes, I've enabled that but I don't think that allows me to choose the
"pdf" target over the "safepdf" target. Or is there something I'm
missing with this option?
Thank you!
Ray
___
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
Kenneth Moreland
*** Sandia National Laboratories
***
*** *** *** email: kmo...@sandia.gov
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
___
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
Re: [CMake] directory traverse guidance
On Tuesday 25 January 2011 07:53:24 Andreas Pakulat wrote:
> On 25.01.11 02:57:27, luxInteg wrote:
> > Greetings
> >
> > I am learning cmake
> >
> > consider my project with two directories dir1 and dir2
> >
> > if I want to:-
> > move to dir1 and add a library libA in dir1
> > move to dir2 and add a library libB in dir2
> > move back to dir1 and add a test testA in dir1
> > move back to dir2 and add a test testB to dir2
> >
> >
> > (the moving back is because of the interdependencies of the tests with
> > the libraries i.e. testA reaquires libB etc))
> >
> > how do I do this?
>
> You don't. All you need is 2 CMakeLists.txt, one in dir1 with libA and
> testA targets and the other in dir2 with libB and testB targets. CMake
> as a declarative language (to a certain extent) does not depend on the
> order in which you declare targets and use them.
Before I made my posting, I tried a setup (as you suggested) but with more
than two directories -lets call this N
my extended setup had dir1 ..dirN
each with
add_library(someLIB ${sourceFiles(1...N)})
add_depedencies(someLIB someTEST)
then
add_test(someTEST someFILE(1...N).c )
target_link_libraries(someTEST
libA
libB
.
libN )
and it failed siting some 'graph' dependency problem.
Basically I have to build a set of tests after building some static libraries
and some of these tests require linking to libraries that occur much later
in the build-scheme. {In other words libA.a might be built and testA (built
in the same directory as liba.A} but it requires linking not only to libA.a
but to the 'later-built' libN.a)
Guidance on how this is 'do-able' will be appreciaed.
sincerely
luxInteg.
___
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
Re: [CMake] CMake 2.8.3 with VC2010 - CHECK_FUNCTION_EXISTS failed
On 1/25/2011 9:14 AM, Dongsheng Song wrote: From the page http://www.cmake.org/Wiki/CMake_FAQ#Is_there_an_option_to_produce_more_.27verbose.27_compiling.3F but when I set CMAKE_START_TEMP_FILE and CMAKE_END_TEMP_FILE to "" , CMakeError.log still include such lines: E:\usr\vs2010\VC\bin\cl.exe @C:\DOCUME~1\DONGSH~1\LOCALS~1\Temp\nm506.tmp OK, so I just learned something about windows 7 today... Welcome to VirtualStore. When you try to edit a file in Program Files as non-admin, Windows silently creates another copy of the file for you to edit. For me it showed up here: ./AppData/Local/VirtualStore/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows.cmake CMake for some reason does not pick up this alternate file, and still uses the original (unchanged) file in Program Files. So, the FAQ is still good, but you need to edit the file as admin to actually change it. -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
Re: [CMake] directory traverse guidance
2011/1/25 luxInteg :
> On Tuesday 25 January 2011 07:53:24 Andreas Pakulat wrote:
>> On 25.01.11 02:57:27, luxInteg wrote:
>> > Greetings
>> >
>> > I am learning cmake
>> >
>> > consider my project with two directories dir1 and dir2
>> >
>> > if I want to:-
>> > move to dir1 and add a library libA in dir1
>> > move to dir2 and add a library libB in dir2
>> > move back to dir1 and add a test testA in dir1
>> > move back to dir2 and add a test testB to dir2
>> >
>> >
>> > (the moving back is because of the interdependencies of the tests with
>> > the libraries i.e. testA reaquires libB etc))
>> >
>> > how do I do this?
>>
>> You don't. All you need is 2 CMakeLists.txt, one in dir1 with libA and
>> testA targets and the other in dir2 with libB and testB targets. CMake
>> as a declarative language (to a certain extent) does not depend on the
>> order in which you declare targets and use them.
>
>
> Before I made my posting, I tried a setup (as you suggested) but with more
> than two directories -lets call this N
>
> my extended setup had dir1 ..dirN
> each with
> add_library(someLIB ${sourceFiles(1...N)})
> add_depedencies(someLIB someTEST)
> then
> add_test(someTEST someFILE(1...N).c )
> target_link_libraries(someTEST
> libA
> libB
> .
> libN )
>
> and it failed siting some 'graph' dependency problem.
>
> Basically I have to build a set of tests after building some static libraries
> and some of these tests require linking to libraries that occur much later
> in the build-scheme. {In other words libA.a might be built and testA (built
> in the same directory as liba.A} but it requires linking not only to libA.a
> but to the 'later-built' libN.a)
Then "TestA" is ill-named :-]
I suggest you build all your libs and non inter-dependent test first
(in the same "dirX" dir)
then any test requiring several libs should be built
in a separate "tests" dir that comes after all "dirX" dirs.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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
Re: [CMake] directory traverse guidance
On 25.01.11 19:09:23, luxInteg wrote:
> On Tuesday 25 January 2011 07:53:24 Andreas Pakulat wrote:
> > On 25.01.11 02:57:27, luxInteg wrote:
> > > Greetings
> > >
> > > I am learning cmake
> > >
> > > consider my project with two directories dir1 and dir2
> > >
> > > if I want to:-
> > > move to dir1 and add a library libA in dir1
> > > move to dir2 and add a library libB in dir2
> > > move back to dir1 and add a test testA in dir1
> > > move back to dir2 and add a test testB to dir2
> > >
> > >
> > > (the moving back is because of the interdependencies of the tests with
> > > the libraries i.e. testA reaquires libB etc))
> > >
> > > how do I do this?
> >
> > You don't. All you need is 2 CMakeLists.txt, one in dir1 with libA and
> > testA targets and the other in dir2 with libB and testB targets. CMake
> > as a declarative language (to a certain extent) does not depend on the
> > order in which you declare targets and use them.
>
>
> Before I made my posting, I tried a setup (as you suggested) but with more
> than two directories -lets call this N
>
> my extended setup had dir1 ..dirN
> each with
> add_library(someLIB ${sourceFiles(1...N)})
> add_depedencies(someLIB someTEST)
So your library depends on the test? This doesn't look like it makes
much sense. Also cmake will already take care of dependencies via
target_link_libraries.
> then
> add_test(someTEST someFILE(1...N).c )
This is actually not going to do anything useful, add_test expects an
executable or the name of a target created by add_executable.
> Basically I have to build a set of tests after building some static libraries
>
> and some of these tests require linking to libraries that occur much later
> in the build-scheme. {In other words libA.a might be built and testA
> (built
> in the same directory as liba.A} but it requires linking not only to
> libA.a
> but to the 'later-built' libN.a)
As I said, this works just fine if you let cmake handle the
dependencies via add_library+add_executable+add_test.
If you still can't make it work, please try out the attached project and
try to make it break by adding more targets, dependencies or source
files and then post the resulting project.
Andreas
--
Learn to pause -- or nothing worthwhile can catch up to you.
cmdep.tar.gz
Description: Binary data
___
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
Re: [CMake] Improvements for cross-referencing in the documentation?
Currently, for formatting the format as described in the readme.txt in the CMake modules directory is used (i.e. not that much formatting). Do higher level programming interfaces exist that can work with message/documentation templates in various file formats? Regards, Markus ___ 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
Re: [CMake] Improvements for cross-referencing in the documentation?
On Tuesday 25 January 2011, SF Markus Elfring wrote: > > Currently, for formatting the format as described in the readme.txt in > > the CMake modules directory is used (i.e. not that much formatting). > > Do higher level programming interfaces exist that can work with > message/documentation templates in various file formats? Not quite sure what you mean. You can get plain text, man, html and docbook help output from cmake. E.g. cmake --help-full .docbook gives you a docbook file, which can then be processed further. The interesting thing is how to get the links into these files initially. Alex ___ 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
[CMake] FindThreads in quiet mode
Hi, Is there any way to use FindThreads in quiet mode without hacking the script itself? In my configuration, I use all Find* modules in quiet mode and only the FindThreads makes noise: -- Looking for include files CMAKE_HAVE_PTHREAD_H -- Looking for include files CMAKE_HAVE_PTHREAD_H - found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE Any workaround possible? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ 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
Re: [CMake] CMake 2.8.3 with VC2010 - CHECK_FUNCTION_EXISTS failed
Thanks, I known the reason why cmke can not found the crt functions:
When I set CFLAGS with double quotation marks:
SET CFLAGS=/nologo /W3 /EHsc /O2 /Oy- /Zi /D"_WIN32_WINNT=0x0502"
/D"WIN32_LEAN_AND_MEAN=1"
Then cmake can issued invalid command lines like this:
CL.EXE /nologo /nologo /W3 /EHsc /O2 /Oy- /Zi /D;_WIN32_WINNT=0x0502"
/D"WIN32_LEAN_AND_MEAN=1" /DWIN32 /D_WINDOWS /W3 /Zm1000
-DCHECK_FUNCTION_EXISTS=exp" /D_DEBUG /MDd /Zi /Ob0 /Od /GZ
/FoCMakeFiles\cmTryCompileExec.dir\CheckFunctionExists.c.obj
/FdC:\var\tmp\CMakeFiles\CMakeTmp\cmTryCompileExec.pdb -c
C:\opt\CMake-2.8\share\cmake-2.8\Modules\CheckFunctionExists.c
This first double quotation mark was replaced by semicolon (" => ;) !!!
But after I changed to with the following line, no errors:
SET CFLAGS=/nologo /W3 /EHsc /O2 /Oy- /Zi /D_WIN32_WINNT=0x0502
/DWIN32_LEAN_AND_MEAN=1
Then I test LDFLAGS:
SET LDFLAGS=/OPT:ICF,REF /MACHINE:X86 /SUBSYSTEM:CONSOLE /RELEASE
Cmake still issued invalid command lines like this:
CL.EXE /nologo @CMakeFiles\cmTryCompileExec.dir\objects1.rsp/DWIN32
/D_WINDOWS /W3 /Zm1000 /GX /GR /D_DEBUG /MDd /Zi /Ob0 /Od /GZ
/FecmTryCompileExec.exe
/FdC:\var\tmp\CMakeFiles\CMakeTmp\cmTryCompileExec.pdb -link
/implib:cmTryCompileExec.lib /version:0.0 /STACK:1000
/machine:X86;/OPT:ICF,REF /MACHINE:X86 /SUBSYSTEM:CONSOLE /RELEASE /debug
/pdbtype:sept /INCREMENTAL:YES /subsystem:console kernel32.lib user32.lib
gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
/machine:X86;/OPT:ICF,REF should be /machine:X86 /OPT:ICF,REF !!!
Regards,
Dongsheng
On Wed, Jan 26, 2011 at 02:19, Bill Hoffman wrote:
> On 1/25/2011 9:14 AM, Dongsheng Song wrote:
>
>
>> From the page
>>
>> http://www.cmake.org/Wiki/CMake_FAQ#Is_there_an_option_to_produce_more_.27verbose.27_compiling.3F
>>
>> but when I set CMAKE_START_TEMP_FILE and CMAKE_END_TEMP_FILE to "" ,
>> CMakeError.log still include such lines:
>>
>> E:\usr\vs2010\VC\bin\cl.exe @C:\DOCUME~1\DONGSH~1\LOCALS~1\Temp\nm506.tmp
>>
>>
> OK, so I just learned something about windows 7 today... Welcome to
> VirtualStore. When you try to edit a file in Program Files as non-admin,
> Windows silently creates another copy of the file for you to edit.
>
> For me it showed up here:
> ./AppData/Local/VirtualStore/Program Files (x86)/CMake
> 2.8/share/cmake-2.8/Modules/Platform/Windows.cmake
>
> CMake for some reason does not pick up this alternate file, and still uses
> the original (unchanged) file in Program Files. So, the FAQ is still good,
> but you need to edit the file as admin to actually change it.
>
> -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
>
___
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
