[CMake] Only install file if it does not exist?
I must be missing something simple?
During "make install" I only want to install a set of files if the do
not exist in destination.
MACRO (COPY_IF_DOES_NOT_EXIST SOURCE DESTINATION)
ADD_CUSTOM_COMMAND (
TARGET COPY
IF (NOT EXISTS ${DESTINATION})
COMMAND ${CMAKE_COMMAND} -E copy ${SOURCE}
${DESTINATION}
ENDIF (NOT EXISTS ${DESTINATION})
)
ADD_CUSTOM_TARGET (
COPY ALL
COMMENT "Copy file: ${SOURCE} ${DESTINATION}"
)
ENDMACRO (COPY_IF_DOES_NOT_EXIST SOURCE DESTINATION)
Works the first time, but if I delete the destination file a make
install won't install it again.
Any help?
--
Bob Tanner | Phone : (952 943-8700
http://www.real-time.com, Linux, OSX, VMware | Fax : (952)943-8500
Key fingerprint = F785 DDFC CF94 7CE8 AA87 3A9D 3895 26F1 0DDB E378
___
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] FindOpenCV.cmake doesn't pick up /usr/local installation FIRST
I must be missing something very obvious. The FindOpenCV.cmake package doesn't seem to respect that I have a custom-built version of OpenCV under /usr/local and goes ahead to grab the ones in /usr always. Also, it outputs Checking GNUCXX version 3/4 to determine OpenCV /opt/net/ path Checking GNUCXX version 3/4 to determine OpenCV /opt/net/ path Checking GNUCXX version 3/4 to determine OpenCV /opt/net/ path Checking GNUCXX version 3/4 to determine OpenCV /opt/net/ path Checking GNUCXX version 3/4 to determine OpenCV /opt/net/ path Checking GNUCXX version 3/4 to determine OpenCV /opt/net/ path in the message box. Why would it outputs 6 times this simple message? Dat Chu ___ 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] macosx fix bundle problems
These lines of output near the beginning: -- warning: *NOT* handled - .app directory case... -- error: fixup_bundle: not a valid bundle ...indicate that fixup_bundle is not getting a .app bundle as its input... The assumption made by fixup_bundle is that there is an executable in the .app/Contents/MacOS folder to begin analyzing. Then, based on what its prerequisites are, various libraries get copied into the bundle as well. This output looks like that initial executable is not there yet. Looks like your "INSTALL(SCRIPT" snippet occurs before the install rule for the bundle executable. Make sure they both occur in the same CMakeLists.txt file and that the script snippet comes after the install rule for the executable. Then it should work like you expect... HTH, David On Sat, Sep 5, 2009 at 4:15 PM, Petr Vanek wrote: > hi all, > > I have a Qt4 application with bundle build support taken from cmake wiki > example. > > When I run "deploy" phase with make install, the correct structure is > created in CMAKE_INSTALL_PREFIX. > > But it looks like cmake's fixup_bundle function from BundleUtilities does > its job only partially. > > All Qt frameworks are fixed correctly to use @executable_path, but the main > binary still contains links to my development environment. > > What could be the issue? > > thanks, > Petr Vanek > > > code: > http://tora.svn.sourceforge.net/viewvc/tora/trunk/tora/ > > 1st make install run: > > rimmer:build-bundle pvanek$ make install > [ 1%] Built target tora_loki_lib > [100%] Built target tora > Install the project... > -- Install configuration: "RELEASE" > Removing Previous TOra.app bundle at /Users/pvanek/oss/tora/bundle/ > Copying TOra.app from the build tree to /Users/pvanek/oss/tora/bundle/ > -- fixup_bundle > -- app='/Users/pvanek/oss/tora/bundle/TOra.app' > -- libs='' > -- dirs='Plugins' > -- warning: *NOT* handled - .app directory case... > -- error: fixup_bundle: not a valid bundle > -- fixup_bundle: done > CMake Warning (dev) at cmake_install.cmake:31 (INCLUDE): > Policy CMP0011 is not set: Included scripts do automatic cmake_policy PUSH > and POP. Run "cmake --help-policy CMP0011" for policy details. Use the > cmake_policy command to set the policy and suppress this warning. > > The included script > > > /Users/pvanek/oss/tora/trunk/tora/build-bundle/TOra_OSX_MakeStandAloneBundle.cmake > > affects policy settings. CMake is implying the NO_POLICY_SCOPE option for > compatibility, so the effects are applied to the including context. > This warning is for project developers. Use -Wno-dev to suppress it. > > -- Installing: /Users/pvanek/oss/tora/bundle/tora.app > -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents > -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents/Info.plist > -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents/MacOS > -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents/MacOS/tora > -- Installing: /Users/pvanek/oss/tora/bundle/tora.app/Contents/Resources > -- Installing: > /Users/pvanek/oss/tora/bundle/tora.app/Contents/Resources/tora.icns > > 2nd make install > rimmer:build-bundle pvanek$ make install > [ 1%] Built target tora_loki_lib > [100%] Built target tora > Install the project... > -- Install configuration: "RELEASE" > Removing Previous TOra.app bundle at /Users/pvanek/oss/tora/bundle/ > Copying TOra.app from the build tree to /Users/pvanek/oss/tora/bundle/ > -- fixup_bundle > -- app='/Users/pvanek/oss/tora/bundle/TOra.app' > -- libs='' > -- dirs='Plugins' > -- fixup_bundle: preparing... > -- fixup_bundle: copying... > -- 1/28: *NOT* copying > '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/MacOS/tora' > -- 2/28: copying '/opt/local/lib/libcrypto.0.9.8.dylib' > -- 3/28: copying '/opt/local/lib/libpng12.0.dylib' > -- 4/28: copying '/opt/local/lib/libssl.0.9.8.dylib' > -- 5/28: copying '/opt/local/lib/libz.1.dylib' > -- 6/28: copying '/opt/local/lib/oracle/libclntsh.dylib.10.1' > -- 7/28: copying '/opt/local/lib/oracle/libocci.dylib.10.1' > -- 8/28: copying '/opt/local/lib/postgresql83/libpq.5.dylib' > -- 9/28: copying > '/opt/local/libexec/qt4-mac/lib/QtCore.framework/Versions/4/QtCore' > -- 10/28: copying > '/opt/local/libexec/qt4-mac/lib/QtGui.framework/Versions/4/QtGui' > -- 11/28: copying > '/opt/local/libexec/qt4-mac/lib/QtNetwork.framework/Versions/4/QtNetwork' > -- 12/28: copying > '/opt/local/libexec/qt4-mac/lib/QtSql.framework/Versions/4/QtSql' > -- 13/28: copying > '/opt/local/libexec/qt4-mac/lib/QtXml.framework/Versions/4/QtXml' > -- 14/28: copying '/opt/local/libexec/qt4-mac/lib/libqscintilla2.5.dylib' > -- fixup_bundle: fixing... > -- 15/28: fixing up > '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/MacOS/tora' > -- 16/28: fixing up > '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/Libraries/libcrypto.0.9.8.dylib' > -- 17/28: fixing up > '/Users/pvanek/oss/tora/bundle/TOra.app/Contents/Libraries/libpng12.0.dylib' > -- 18/28: fixing up > '/Users/pvanek/oss/tora/bu
Re: [CMake] Generated source files and dependencies(+) (Wojciech Migda)
On Tuesday 08 September 2009 02:14:45 pm Wojciech Migda wrote:
> > Why not include it in the foo target, instead of making a new
>
> a_h_gen target and doing extra dependencies manually?
>
> Firstly, we have hundred of source files which may indirectly depend
> generated source files, so we want such information to be covered by
> cmake dependency scanner itself - the problem is that there is no link
> between the library target and the header target.
That's why I suggested
ADD_LIBRARY(foo STATIC a.c ${CMAKE_CURRENT_BINARY_DIR}/a.h)
It creates the generated headers for foo, then does the dependency scanning
for foo, then compiles files.
Here's what I got:
$ make
[ 50%] Generating a.h
Scanning dependencies of target foo
[100%] Building C object CMakeFiles/foo.dir/a.o
Linking C static library libfoo.a
If that doesn't work for your case, can you be more specific on why it doesn't?
Clint
>
> By no means we want to specify such dependencies manually - that would
> be a nightmare.
>
> If we skip the a_h_gen target the header generation target will not
> appear in Makefile2, which I think is one of the required links for
> everything to work. The last remaining link is missing (which we may
> mimic by hand with the add_dependencies command) by I don't know how
> to fix it so it becomes automatic within the build system and
> dependency scanner.
>
> -Wojciech
>
>
>
> --
> Marcin Gortat – gwiazda NBA w naszej reprezentacji!
> Czytaj wiecej >> http://link.interia.pl/f232a
>
> ___
> 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
Re: [CMake] Patch for FindBoost.cmake
On 08.09.09 13:47:56, Joseph Garvin wrote: > Without this patch FindBoost.cmake will look for the wrong filenames > when linking against a release build of boost. For debug it looks for > the correct names, but for release it adds spurious hyphens. It looks > like the hyphens used to be necessary, then the code changed and > someone changed debug to match to the change but forgot to update > release. > > I'd love to see this in 2.6.5 so I don't have to ship a > FindBoost.cmake replacement with my app :P I don't see why this patch would be necessary. The boost_(MULTITHREAD|STATIC|ABI|COMPILER) variables already start with a hyphen, so your patch will add 2 hyphens to the names that are being searched. There's a difference between the debug and the release find_library calls, but thats just adding _boost_ABI_TAG in the debug-case. This is with CMake from the 2.6 branch Andreas -- It may or may not be worthwhile, but it still has to be done. ___ 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] Generated source files and dependencies(+) (Wojciech Migda)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Why not include it in the foo target, instead of making a new a_h_gen target and doing extra dependencies manually? Firstly, we have hundred of source files which may indirectly depend generated source files, so we want such information to be covered by cmake dependency scanner itself - the problem is that there is no link between the library target and the header target. By no means we want to specify such dependencies manually - that would be a nightmare. If we skip the a_h_gen target the header generation target will not appear in Makefile2, which I think is one of the required links for everything to work. The last remaining link is missing (which we may mimic by hand with the add_dependencies command) by I don't know how to fix it so it becomes automatic within the build system and dependency scanner. - -Wojciech -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKprs10iFl+nAyImcRAo5XAJ4scpKe/E9g5uTZcFPyLYroJmD0oACghdom T6TR/kPv+kLYga/wCXObbwA= =q652 -END PGP SIGNATURE- -- Marcin Gortat – gwiazda NBA w naszej reprezentacji! Czytaj wiecej >> http://link.interia.pl/f232a ___ 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] Generated source files and dependencies(+) (Wojciech Migda)
Why not include it in the foo target, instead of making a new a_h_gen target
and doing extra dependencies manually?
-
INCLUDE_DIRECTORIES( ${CMAKE_CURRENT_SOURCE_DIR} )
SET_SOURCE_FILE_PROPERTIES( ${CMAKE_CURRENT_SOURCE_DIR}/a.h PROPERTIES
GENERATED TRUE )
ADD_CUSTOM_COMMAND(
OUTPUT "${CMAKE_CURRENT_SOURCE_DIR}/a.h"
COMMAND echo \"\#define STAMP \\\"\" `date` \"\\\"\" > a.h
DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/a.txt"
)
ADD_LIBRARY( foo STATIC a.c ${CMAKE_CURRENT_SOURCE_DIR}/a.h)
Clint
On Tuesday 08 September 2009 01:31:32 pm Wojciech Migda wrote:
> Hi,
>
> some time ago there was a discussion, which has highlighted problem I
> am facing now, but it did not provide final conclusions
> (http://www.cmake.org/pipermail/cmake/2008-September/024093.html).
>
> Take this example:
>
> --
> INCLUDE_DIRECTORIES( ${CMAKE_CURRENT_SOURCE_DIR} )
>
> SET_SOURCE_FILE_PROPERTIES( ${CMAKE_CURRENT_SOURCE_DIR}/a.h PROPERTIES
> GENERATED TRUE )
>
> ADD_CUSTOM_COMMAND(
> OUTPUT "${CMAKE_CURRENT_SOURCE_DIR}/a.h"
> COMMAND echo \"\#define STAMP \\\"\" `date` \"\\\"\" > a.h
> DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/a.txt"
> )
>
> ADD_CUSTOM_TARGET( a_h_gen DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/a.h )
>
> ADD_LIBRARY( foo STATIC a.c )
> -
>
> Here we have file a.c which includes file a.h.
> a.h is generated, with dependency on a.txt.
>
> What I'd expect from the above (and what ZNV hinted in the 2008
> thread) building foo library should check dependencies of a.c and if
> a.h doesn't exist generate it or it a.txt has changed regenerate a.h
>
> However, files generated with cmake 2.6.4 show that:
>
> 1. in Makefile2 a.c has no dependencies on a.h or a_h_gen
> 2. depend.make for foo library has dependency on a.h only if a.h
> existed at the time of cmake execution or during dependency scanning
> for a.c
>
> The result is that building foo doesn't generate a.h nor a.h is
> refreshed if a.txt changed even though depend.make for foo lists a.h
> as its dependency. If I add the following line at the end:
>
> ADD_DEPENDENCIES( foo a_h_gen )
>
> a dependency for foo on a_h_gen will appear in Makefile2 and
> everything will work as expected.
>
> This however, in a real life example I am working on there are
> hundreds of source files and tens of libraries which indirectly may
> depend on a generated header and thus manual specification of
> dependency between built library and generated file is simply impractical.
>
> Thus, my question is whether I am missing something in my example
> CMakeLists.txt or cmake at this stage is simply unable to handle such
> situation.
>
> In the 2008 discussion ZNV illustrated exactly the same situation by
> the single vs. two-level dependency illustration, and Esben's response
> was that properly constructed CMakeLists.txt file shall enforce single
> level of dependencies. Nonetheless, the example above shows that it is
> not the case.
>
> Any hints allowing me to reach the desired cmake behaviour will be
> appreciated. THANKS.
>
> -Wojciech
>
>
> --
> Wykonaj diagnostyke skory i odbierz swoj Prezent!
> http://link.interia.pl/f22f1
>
> ___
> 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
[CMake] Generated source files and dependencies(+) (Wojciech Migda)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
some time ago there was a discussion, which has highlighted problem I
am facing now, but it did not provide final conclusions
(http://www.cmake.org/pipermail/cmake/2008-September/024093.html).
Take this example:
- --
INCLUDE_DIRECTORIES( ${CMAKE_CURRENT_SOURCE_DIR} )
SET_SOURCE_FILE_PROPERTIES( ${CMAKE_CURRENT_SOURCE_DIR}/a.h PROPERTIES
GENERATED TRUE )
ADD_CUSTOM_COMMAND(
OUTPUT "${CMAKE_CURRENT_SOURCE_DIR}/a.h"
COMMAND echo \"\#define STAMP \\\"\" `date` \"\\\"\" > a.h
DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/a.txt"
)
ADD_CUSTOM_TARGET( a_h_gen DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/a.h )
ADD_LIBRARY( foo STATIC a.c )
- -
Here we have file a.c which includes file a.h.
a.h is generated, with dependency on a.txt.
What I'd expect from the above (and what ZNV hinted in the 2008
thread) building foo library should check dependencies of a.c and if
a.h doesn't exist generate it or it a.txt has changed regenerate a.h
However, files generated with cmake 2.6.4 show that:
1. in Makefile2 a.c has no dependencies on a.h or a_h_gen
2. depend.make for foo library has dependency on a.h only if a.h
existed at the time of cmake execution or during dependency scanning
for a.c
The result is that building foo doesn't generate a.h nor a.h is
refreshed if a.txt changed even though depend.make for foo lists a.h
as its dependency. If I add the following line at the end:
ADD_DEPENDENCIES( foo a_h_gen )
a dependency for foo on a_h_gen will appear in Makefile2 and
everything will work as expected.
This however, in a real life example I am working on there are
hundreds of source files and tens of libraries which indirectly may
depend on a generated header and thus manual specification of
dependency between built library and generated file is simply impractical.
Thus, my question is whether I am missing something in my example
CMakeLists.txt or cmake at this stage is simply unable to handle such
situation.
In the 2008 discussion ZNV illustrated exactly the same situation by
the single vs. two-level dependency illustration, and Esben's response
was that properly constructed CMakeLists.txt file shall enforce single
level of dependencies. Nonetheless, the example above shows that it is
not the case.
Any hints allowing me to reach the desired cmake behaviour will be
appreciated. THANKS.
- -Wojciech
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKprET0iFl+nAyImcRAritAJ94VawRLcOh55U6uBu+QECWbVKB7wCffST5
TYAJVZC8mGhNp3yO9fVue2Y=
=LYc3
-END PGP SIGNATURE-
--
Wykonaj diagnostyke skory i odbierz swoj Prezent!
http://link.interia.pl/f22f1
___
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] Patch for FindBoost.cmake
Without this patch FindBoost.cmake will look for the wrong filenames when linking against a release build of boost. For debug it looks for the correct names, but for release it adds spurious hyphens. It looks like the hyphens used to be necessary, then the code changed and someone changed debug to match to the change but forgot to update release. I'd love to see this in 2.6.5 so I don't have to ship a FindBoost.cmake replacement with my app :P findboost.patch 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] don't auto-clean generated files?
On Tue, Sep 8, 2009 at 10:36 AM, Alexander
Neundorf wrote:
> On Tuesday 08 September 2009, Aaron Turner wrote:
>> On Mon, Sep 7, 2009 at 1:00 PM, Alexander
>>
>> Neundorf wrote:
>> > On Monday 07 September 2009, Aaron Turner wrote:
>> >> I'm look for a way to tell cmake to not automatically remove certain
>> >> auto-generated files when the 'clean' target is invoked.
>> >>
>> >> Basically I have:
>> >>
>> >> add_custom_command(OUTPUT tcpbridge_opts.c tcpbridge_opts.h
>> >> COMMAND ${AUTOGEN} -L tcpedit tcpbridge_opts.def
>> >> DEPENDS tcpbridge_opts.def
>> >> )
>> >>
>> >> And of course, other files depend on tcpbridge_opts.[ch]
>> >>
>> >> The problem is that I don't want tcpbridge_opts.[ch] deleted when
>> >> 'make clean' is run.
>> >
>> > Why don't you want this file to be deleted ?
>>
>> Because, counter to my general rule of thumb of never committing
>> generated code, I've decided to check in some generated code. These
>> files also need to be shipped in the source tarballs. Long story
>> short: The templates used to generate the files is *very* particular
>> about what version of autogen is used and I find I get far too many
>> users checking out the code who have problems when they use the wrong
>> version.
>
> That's indeed what I was assuming, and for this case add_custom_target()
> should be used.
>
>> > Maybe an ADD_CUSTOM_TARGET() would be more suitable ?
>>
>> I was under the impression that the outputs of targets are always
>> deleted when 'make clean' is run... at least that's how it seems to
>> work.
>
> With ADD_CUSTOM_TARGET() no output files are specified, so they cannot be
> cleaned.
> Here's a simple example:
> $ cat ../CMakeLists.txt
> cmake_minimum_required(VERSION 2.6)
>
> add_custom_target(MakeMyFiles COMMAND touch abc )
>
> add_executable(foo main.c)
> $
>
> This gives you a custom target "MakeMyFiles", which is only executed if you
> explicitely build it. And I think that's also what you actually want.
> I would suggest to have the custom target generate the files in the build
> tree, and then you can do with them what you want. You can copy them into the
> source tree, check them into the version control system, etc.
>
> If you use add_custom_command() you will always have the rule to regenerate
> the files in your makefiles, and so your users can still get the problem
> (since the custom command would *have* to depend on the input file) if for
> whatever reason their template file got a newer date than the generated file.
Well proper dependency tracking is a good thing IMHO. That's why I
use a build system like cmake- so I don't have to remember what files
have changed and the ripple effects of those changes.
Honestly I'm totally OK with breakage for users foolish enough to
change a timestamp on the template file- who knows, maybe they know
what they're doing. They can always do an 'svn revert' to put things
back the way they were if it breaks. I know I'm stupid enough to
forget regenerating the files after making a slight change. :)
Anyways, I have a working solution it seems- just not very elegant
since it's semi-global. I'll open up a feature request to make an
equivalent CLEAN_NO_CUSTOM property for individual files.
--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
-- Benjamin Franklin
___
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] don't auto-clean generated files?
On Tuesday 08 September 2009, Aaron Turner wrote:
> On Mon, Sep 7, 2009 at 1:00 PM, Alexander
>
> Neundorf wrote:
> > On Monday 07 September 2009, Aaron Turner wrote:
> >> I'm look for a way to tell cmake to not automatically remove certain
> >> auto-generated files when the 'clean' target is invoked.
> >>
> >> Basically I have:
> >>
> >> add_custom_command(OUTPUT tcpbridge_opts.c tcpbridge_opts.h
> >> COMMAND ${AUTOGEN} -L tcpedit tcpbridge_opts.def
> >> DEPENDS tcpbridge_opts.def
> >> )
> >>
> >> And of course, other files depend on tcpbridge_opts.[ch]
> >>
> >> The problem is that I don't want tcpbridge_opts.[ch] deleted when
> >> 'make clean' is run.
> >
> > Why don't you want this file to be deleted ?
>
> Because, counter to my general rule of thumb of never committing
> generated code, I've decided to check in some generated code. These
> files also need to be shipped in the source tarballs. Long story
> short: The templates used to generate the files is *very* particular
> about what version of autogen is used and I find I get far too many
> users checking out the code who have problems when they use the wrong
> version.
That's indeed what I was assuming, and for this case add_custom_target()
should be used.
> > Maybe an ADD_CUSTOM_TARGET() would be more suitable ?
>
> I was under the impression that the outputs of targets are always
> deleted when 'make clean' is run... at least that's how it seems to
> work.
With ADD_CUSTOM_TARGET() no output files are specified, so they cannot be
cleaned.
Here's a simple example:
$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
add_custom_target(MakeMyFiles COMMAND touch abc )
add_executable(foo main.c)
$
This gives you a custom target "MakeMyFiles", which is only executed if you
explicitely build it. And I think that's also what you actually want.
I would suggest to have the custom target generate the files in the build
tree, and then you can do with them what you want. You can copy them into the
source tree, check them into the version control system, etc.
If you use add_custom_command() you will always have the rule to regenerate
the files in your makefiles, and so your users can still get the problem
(since the custom command would *have* to depend on the input file) if for
whatever reason their template file got a newer date than the generated file.
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] INSTALL query (itk,cmake)
Hi, I finally attempted to enable INSTALL support in my CMakeLists file for a project that uses ITK. However when I install by this method the program loses the location of the ITK libraries. __ which itk_flop /dls/i12/software/64/bin/itk_flop itk_flop itk_flop: error while loading shared libraries: libITKCommon.so.3.15: cannot open shared object file: No such file or directory _ Simply copying the built project files into the installation destination does not lose the location. cp itk_flop /dls/i12/software/64/bin/ which itk_flop /dls/i12/software/64/bin/itk_flop itk_flop Little program to use itk reading and writing to convert file formats including reading a series of files and writing an orthogonal series Series Usage: itk_flop inbasename.xxx first last outbasename.yyy __ What should be done? I'd like other users to be able to issue 'make install' and have it work for them. I used these lines in my CMakeLists.txt file, as suggested by http://www.itk.org/Wiki/CMake:Install_Commands SET(CMAKE_INSTALL_PREFIX "/dls/i12/software/64" CACHE PATH "Local installation prefix" FORCE ) ... INSTALL(TARGETS scanpar itk_flop itk_series_readwrite itk_parallel_project itk_readwrite_series RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib) In ccmake I've selected the followign, which is indeed the location of InsightToolkit ITK_DIR /dls/i12/software/64/lib/InsightToolkit Thanks, Robert This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom ___ 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] Finding Qt4 binaries under Windows
On 05.09.2009 18:49, Alexander Neundorf wrote: But just for the fun of it, I also tried Pau's find_package(Qt4 PATHS "C:/Qt/4.5.1") If you use PATHS, cmake looks for a Qt4Config.cmake file, which does not exist. So don't use PATHS or HINTS, just do: find_package(Qt4) (maybe add the REQUIRED keyword). This will load FindQt4.cmake. FindQt4.cmake then tries to find qmake. This is where you can help. Thanks a lot, Alex, that finally was a helpful answer! FYI, in a batch file I'm now doing: ---8<--- : Search QTDIR first, then some guessed paths. set CMAKE_PREFIX_PATH=%QTDIR%;C:\Qt\4.5.2;C:\Qt\4.5.1;C:\Qt\4.5.0;%CMAKE_PREFIX_PATH% : Generate the project files in the output directory. pushd VS2008-Win32 cmake -G "Visual Studio 9 2008" .. if errorlevel 1 pause popd ---8<--- CMake would search QTDIR itself, but only *after* CMAKE_PREFIX_PATH, which is why I made QTDIR the first path in CMAKE_PREFIX_PATH. This now seems to work how I would like it to work. Thanks again. -- Sebastian Schuberth ___ 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] Mac OSX: How to force the CMAKE_OSX_ARCHITECTURES value
Hello I wuld like generate my makefile projet by running 'cmake' in command line: cmake -D "BUILD_EXAMPLES:BOOL=OFF" -D "CMAKE_CXX_FLAGS:STRING=-Wall" : : -D "CMAKE_OSX_ARCHITECTURES:STRING=i386" : : But CMAKE_OSX_ARCHITECTURES value is always force by cmake and set to the default value "ppc;i386;ppc64;x86_64". The line -D "CMAKE_OSX_ARCHITECTURES:STRING=i386" has no effect. I try a second solution: cmake -C MyConfig.cmake and MyConfig.cmake contain: : : SET( CMAKE_OSX_ARCHITECTURES "i386" CACHE STRING "OX Architectures" FORCE) : : But it the same result. How can I force the value ? Is it possible ? Regards, Thomas -- Thomas FEUVRIER - Ingénieur de développement / Traitement des images CS / ESPACE / Départ. Information Géographique & Image +33 (0)561 17 65 16 / FAX : +33 (0)561 34 84 15 / thomas.feuvr...@c-s.fr ___ 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
