Re: [CMake] Let CMake convert CMAKE_MODULE_PATH to absolute path
On Fri, 2009-09-04 at 21:48 +0200, Alexander Neundorf wrote: On Tuesday 25 August 2009, Marcel Loose wrote: Hi all, I've been bitten by this more than once. When specifying a module path on the command line, you must not forget to make this an absolute path, otherwise calling a macro from a (CMakeLists.txt file in a) subdirectory will fail. Would it be an idea to let CMake always convert a relative module path to an absolute path, before putting it in the cache? Hmm, that would be special handling for that one variable. I guess it should be interpreted as relative to CMAKE_BINARY_DIR ? Wouldn't it be confusing if this one variable would be handled differently than all others ? Alex Well, I don't know how many variables might be affected by this. Maybe it's breaking more things that it's supposed to fix. I was just wondering, because I ran into this problem more than once. Besides, you do not have to specify the absolute path to the CMakeLists.txt file you're feeding to cmake (I agree, though, that that's not exactly the same thing.) Best regards, Marcel Loose. ___ 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] FindThreads: the odd one out?
On Fri, 2009-09-04 at 21:55 +0200, Alexander Neundorf wrote: On Sunday 30 August 2009, Philip Lowman wrote: On Fri, Aug 28, 2009 at 4:29 AM, Marcel Loose lo...@astron.nl wrote: Hi all, Up till now I've been using the not officially supported and released FindPthreads.cmake macro to check for the presence of pthreads. However, the maintainer of that macro wrote (a comment in Mantis) that he would drop support for FindPthreads in favor of the more general and officially supported FindThreads.cmake macro. However, I have some difficulty understandig how to properly use FindThreads.cmake. Contrary to most FindXXX macros it does not set THREADS_INCLUDE_DIR and THREADS_LIBRARY. It does set some *_INIT variables, but I thought that *_INIT variables were only used by CMake itself to preset compiler and linker flags, and that these were not to be used outside. Could someone shed a light on this? I could also use some illumination on this. I get that you're supposed to use CMAKE_THREAD_LIBS_INIT with target_link_libraries() because libpthread isn't always called libpthread, but it also looks like CMAKE_THREAD_LIBS_INIT can also be set to -pthread in the event the system doesn't have a pthread library and it's supposed to be a compile definition thing...??? If so, why one variable instead of two? Also what systems does this happen on? I'm not sure if anyone is actually using the pthreads-win32 stuff I wrote This one: http://sourceware.org/pthreads-win32/ ? 3 years ago I was using it (to make that software easily portable). I also think FindThreads.cmake is somewhat strange, doesn't it basically load the thread library of the current platform ? That means that you get different APIs on different platforms and therefor need different code ? Alex It turns out there different versions of the FindPthreads macro lying around :-(. I was refering to this http://www.vtk.org/Bug/file_download.php?file_id=2282type=bug version, which can be found here http://www.vtk.org/Bug/view.php?id=9074 Best regards, Marcel Loose. ___ 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] FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH
Hi all, In fact the subject line says it all. To be compliant with the naming conventions proposed in the Modules/readme.txt file, FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH. To avoid breaking existing software, it would be best to simply just add a definition for PYTHON_INCLUDE_DIR. Best regards, Marcel Loose. ___ 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] out of source command line flag
Eric Noulard wrote: Fair enough, my tortuous mind was tracking the build tree yours is tracking the source tree, this is obviously a better choice. My E3) case still remains, you really don't want to mess-up an existing build tree with a unrelated source tree. I know however that my proposal does not solve the other problem regarding ignoring path-to-existing-build raised in this thread. That use case will not be dropped. I think the two-path auto-magic command line interpretation approach will work well if implemented correctly, and will happily review a patch. However, see my other suggestion below. In the current one arg cmake invocation we should have a way to detect/avoid an unvoluntary in-source build. Currently we cannot. This is the key idea. I've thought about possible solutions to this in the past but never found time to implement any. My idea is to have an optional InSource.cmake file written by the project in the source tree. If CMake sees an attempt to build in-source, it can load this file before touching the source tree at all. The file could do one of the following: 1.) Simply error-out and tell the user to build out-of-source. The source tree will remain clean. 2.) Compute the path to a build tree for CMake to auto-magically substitute for an in-source build. Likely it would be just source-tree/build or some convention the project prefers. 3.) Other ideas? One gotcha with action #2 is that CMake knows nothing about the target platform at the point the file is loaded, so projects would be unable to compute a path like build-x86_64. -Brad ___ 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] cpack install problem
that was the problem. I didn't realize that security updates to MSVSE would change the versioning. I was rebuilding vtk etc. but overlooked tcl/tk. Once I rebuilt *everything* apps install and run fine. Thanks for all your help. Dean -Original Message- From: Bill Hoffman [mailto:bill.hoff...@kitware.com] Sent: September-03-09 4:36 PM To: John Drescher Cc: dean.ing...@camris.ca; cmake@cmake.org Subject: Re: [CMake] cpack install problem John Drescher wrote: assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0 dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.VC80.CRT version=8.0.50727.762 processorArchitecture=x86 publicKeyToken=1fc8b3b9a1e18e3b/assemblyIdentity /dependentAssembly /dependency dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.VC80.CRT version=8.0.50727.4053 processorArchitecture=x86 publicKeyToken=1fc8b3b9a1e18e3b/assemblyIdentity /dependentAssembly /dependency dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.VC80.CRT version=8.0.50608.0 processorArchitecture=x86 publicKeyToken=1fc8b3b9a1e18e3b/assemblyIdentity /dependentAssembly /dependency The fix is to rebuild everything with the same version (SP) of visual studio. A single exe should not have more than one of these things in it. If it does then you have to do the redist thing. If it only has one, which is possible, then you can ship the libraries and not have to install into the system with redist. If there is one .obj or one .dll that was built with a slight different version of VS, then you get this problem, and the side by side manifest will not work. The redist.exe works by installing all of them into the system. It requires administrator rights to do this, and installs them for the whole computer. -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] out of source command line flag
Well...I didn't foresee such a discussion on the topic but have actually heard some interesting new things brought up...so I guess I can chime in too. 1. Being able to call cmake with $ cmake build dir source dir Although it is better than what we have now, I like the explicit nature of the -B build dir (or other flag) coming before the directory specification. It makes it very clear what is going to happen. It also doesn't tie you to a particular ordering of the command line arguments. 2. I really like the idea of being able to specify a *default* out of source directory to prevent in source builds altogether. From a developer standpoint...if you could have that option be in the CMakeLists.txt file (maybe before PROJECT) then I think that would be the most obvious place for future maintainers to look. If you start adding other files (i.e. InSource.cmake) you add more places where people need to look for configuration options. Now, having said that...I don't know enough about the caching system to know if it is reasonable to even have such an option in a CMakeLists.txt file before the build directory is known. Note, that this option (as I see it) still does not handle the use case I showed initially where you can create various build directories with different build flags...I see this option as only providing a default build directory. ~Roman On Mon, Sep 7, 2009 at 10:06 AM, Eric Noularderic.noul...@gmail.com wrote: 2009/9/7 Brad King brad.k...@kitware.com: Eric Noulard wrote: Fair enough, my tortuous mind was tracking the build tree yours is tracking the source tree, this is obviously a better choice. My E3) case still remains, you really don't want to mess-up an existing build tree with a unrelated source tree. I know however that my proposal does not solve the other problem regarding ignoring path-to-existing-build raised in this thread. That use case will not be dropped. I think the two-path auto-magic command line interpretation approach will work well if implemented correctly, and will happily review a patch. I personnally won't be able to provide a patch soon, just to be clear that other may try it without fear :-) However, see my other suggestion below. In the current one arg cmake invocation we should have a way to detect/avoid an unvoluntary in-source build. Currently we cannot. This is the key idea. I've thought about possible solutions to this in the past but never found time to implement any. My idea is to have an optional InSource.cmake file written by the project in the source tree. If CMake sees an attempt to build in-source, it can load this file before touching the source tree at all. The file could do one of the following: 1.) Simply error-out and tell the user to build out-of-source. The source tree will remain clean. 2.) Compute the path to a build tree for CMake to auto-magically substitute for an in-source build. Likely it would be just source-tree/build or some convention the project prefers. 3.) Other ideas? One gotcha with action #2 is that CMake knows nothing about the target platform at the point the file is loaded, so projects would be unable to compute a path like build-x86_64. I like the idea, however could you explain why you would rather add an optional InSource.cmake file and not a new CMake macro that may be called before PROJECT in a CMakeLists.txt? If you were to implement the extra-file thing why would you limit its usage to the InSource check? Let's say that we call it PreCMakeTimeChecks.cmake or something better: If it exists the file will be loaded by CMake in something like CMake -P processing mode: A) BUT some vars needs to be defined, at least CMAKE_SOURCE_DIR CMAKE_BINARY_DIR (in fact currently in processing mode those var seems to be defined to working directory) B) The source tree won't be touched during this step (thus any SET will ignore CACHE argument i.e. no CMakeCache.txt interaction) C) The variable SET in this file may be passed to the current CMake process as if there were provided by -D var:type=value. including the may-be-overwritten CMAKE_BINARY_DIR which specify the wanted build tree. 3) Other ideas? yes, like I said project (or user) may give some typical (but many ) PreCMakeTimeChecks.cmake files in order ease 1 liner configuration. This is just the same as CMake . default behavior but in this case you may have several defaults at hand. These kind of files may even be generated by cmake-gui: http://www.cmake.org/pipermail/cmake/2009-September/031727.html Summary is: we can introduce (optional) Pre CMake processing capability which may not be restricted to the InSource handling case. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com
Re: [CMake] out of source command line flag
On 2009-09-07 08:43-0400 Brad King wrote:
I know however that my proposal does not solve the other problem
regarding ignoring path-to-existing-build raised in this thread.
That use case will not be dropped. I think the two-path auto-magic
command line interpretation approach will work well if implemented
correctly, and will happily review a patch. However, see my other
suggestion below.
In the current one arg cmake invocation we should have a way to
detect/avoid an unvoluntary in-source build.
Currently we cannot.
This is the key idea. I've thought about possible solutions to this
in the past but never found time to implement any. My idea is to
have an optional InSource.cmake file written by the project in the
source tree. If CMake sees an attempt to build in-source, it can
load this file before touching the source tree at all. The file
could do one of the following:
1.) Simply error-out and tell the user to build out-of-source.
The source tree will remain clean.
2.) Compute the path to a build tree for CMake to auto-magically
substitute for an in-source build. Likely it would be just
source-tree/build or some convention the project prefers.
3.) Other ideas?
One gotcha with action #2 is that CMake knows nothing about the
target platform at the point the file is loaded, so projects
would be unable to compute a path like build-x86_64.
Projects can obviously do (1) already by the appropriate IF(CMAKE_BINARY_DIR
STREQUAL ${CMAKE_SOURCE_DIR}) logic. However, I suspect most projects
prefer to give their users the flexibility to choose in-source builds.
Instead of (2) which requires users of a particular project that adopts it
to never have access to in-source builds, I far prefer the idea of giving
build systems access to the path where cmake was invoked as a CMake variable
(say CMAKE_INVOCATION_DIR). That allows projects to demand (if they like) to
error out IF(NOT CMAKE_BINARY_DIR STREQUAL ${CMAKE_INVOCATION_DIR} AND
CMAKE_BINARY_DIR STREQUAL ${CMAKE_SOURCE_DIR}) which would disallow _just_
the problematic case where users try an in-source build, then attempt to
invoke cmake from a different location other than the top of the existing
build == source tree.
Alan
That would allow users to use
cmake .
or to error out when users
are attempting to follow an in-source build with a possible out-of-source
build.
detect the problematic case
(invocation path != build-tree path AND build-tree path == source-tree path)
where an attempt is made to do an in-source build from some other location
using the path-to-existing-build interpretation. It's this problematic
case (which can only occur if there is an in-source build followed by an
out-of-source build attempt) that I believe most projects want to avoid
rather than precluding in-source builds altogether as in (1).
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
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 using CMAKE_CXX_FLAGS
On Sep 5, 2009, at 3:31 PM, Alexander Neundorf wrote:
[...]
Can you please try the attached patch ?
I have tried it and I have got the desired result, i.e. the compiler
driver is invoked for compilation on the assembly sources. The
CMakeLists.txt file contains:
ENABLE_LANGUAGE(ASM-GCC)
set (ASM_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/asm.S)
add_library (mylib ${CXX_LIBRARY_TYPE} somesrc.cpp ${ASM_SRCS})
which results in:
[ 2%] Building ASM-GCC object .../asm.S.o
cd projdir /usr/bin/gcc -Isomeinclude -c asm.S -o bindir/asm.S.o
As I said before, and after more thinking, I believe that in my case a
better solution is to have the assembly source compiled like the other
sources in the project. This might not be the ideal solution for other
projects.
So, a better solution for me is to have:
set_source_files_properties (${ASM_SRCS} PROPERTIES LANGUAGE CXX)
Thanks!
-J
___
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] out of source command line flag
An important clarification is that any kind of PreConfigure.cmake file would be loaded without any build tree or cache. Anything it does won't make it into the real CMakeLists.txt processing...no variables or cache settings. The file would be an interface to tell CMake about some project information or preferences. This could include things like: I like this idea as it provides a good place to put any *init* related config. Providing a default build directory seems very reasonable to me and I think that many project would actually benefit from such a feature. IMHO in-source builds interfere too much with the source tree (obviously) and out of source builds (and all the intermediate files) are much easier to ignore with version control systems. On top of the PreConfigure.cmake file I still think the -B build dir flag might have be of benefit... unless the PreConfigure.cmake allows you to setup more than one build directory and the options that will be defined in it? That would be rather useful as you could setup debug and release directories and specify the default directory all from one file. Maybe this starts becoming more of a project preferences or setup file... ~Roman On Mon, Sep 7, 2009 at 11:28 AM, Brad Kingbrad.k...@kitware.com wrote: Roman Shtylman wrote: Well...I didn't foresee such a discussion on the topic but have actually heard some interesting new things brought up...so I guess I can chime in too. 1. Being able to call cmake with $ cmake build dir source dir Although it is better than what we have now, I like the explicit nature of the -B build dir (or other flag) coming before the directory specification. It makes it very clear what is going to happen. It also doesn't tie you to a particular ordering of the command line arguments. That's a good point. While it might be obvious to CMake which directory is build and which is source, it might not to the human reading the command line. I'll vote for the explicit switch. 2. I really like the idea of being able to specify a *default* out of source directory to prevent in source builds altogether. From a developer standpoint...if you could have that option be in the CMakeLists.txt file (maybe before PROJECT) then I think that would be the most obvious place for future maintainers to look. A lot of things happen before CMakeLists.txt even starts running, and files will have already been written to the build tree. If you start adding other files (i.e. InSource.cmake) you add more places where people need to look for configuration options. Eric's point is good. The file could be used for other things too. A *long* time ago we tried to create a PreLoad.cmake file for some purpose I can't remember. We never got it working well, but it was not quite the same thing we are discussing here. 1.) Default build directory for attempted in-source builds 2.) Eric's option C...default cache entries. For the CMake GUI they could appear before the first Configure starts. 3.) A mapping from --prefix-style options to cache entries. The output of cmake --help src-tree|bld-tree could include these options as project-specific help. Idea #3 is a long-requested feature anyway. -Brad ___ 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] out of source command line flag
2009/9/7 Alan W. Irwin ir...@beluga.phys.uvic.ca:
On 2009-09-07 08:43-0400 Brad King wrote:
1.) Simply error-out and tell the user to build out-of-source.
The source tree will remain clean.
Projects can obviously do (1) already by the appropriate IF(CMAKE_BINARY_DIR
STREQUAL ${CMAKE_SOURCE_DIR}) logic.
Yes you can do that but when you reach that point in your CMakeLists.txt
the source tree is **ALREADY** cluttered with unwanted files including
a CMakeCache.txt.
This is precisely the point of bug:
http://public.kitware.com/Bug/view.php?id=6672
However, I suspect most projects prefer to give their users the
flexibility to choose in-source builds.
Yes you are right I do support in-source for my CMake-powered project
but I'd rather be able to warn my user about
the evilness of in-source build when they can simply avoid it :-)
I may require -DFORCE_IN_SOURCE in order to make the
user fully aware of what he is doing.
That way I may be able to avoid the explanation for cleaning
a use as build tree source tree.
2.) Compute the path to a build tree for CMake to auto-magically
substitute for an in-source build. Likely it would be just
source-tree/build or some convention the project prefers.
Instead of (2) which requires users of a particular project that adopts it
to never have access to in-source builds,
Agreed,
there should a way for the user to **explicitely** tells that he wants
an in-source
build and authorize it with some -DFORCE_IN_SOURCE.
I just dislike the default behavior which makes me unable to
warn about in-source build efficiently.
I far prefer the idea of giving
build systems access to the path where cmake was invoked as a CMake variable
(say CMAKE_INVOCATION_DIR). That allows projects to demand (if they like) to
error out IF(NOT CMAKE_BINARY_DIR STREQUAL ${CMAKE_INVOCATION_DIR} AND
CMAKE_BINARY_DIR STREQUAL ${CMAKE_SOURCE_DIR}) which would disallow _just_
the problematic case where users try an in-source build, then attempt to
invoke cmake from a different location other than the top of the existing
build == source tree.
Yes that's a good point,
but at that point your user discovers that he has already done an
in-source build
(may be because he overlooked the written build procedure) and ends up asking
on his favorite mailing list how he can clean his source tree.
If he has previously **explicitely** required in-source build he won't
be puzzled
by the latest message. If he has done the first in-source config. by mistake
he will be puzzled by the error message.
However your idea is good I can error out a big explanation
on the in-source vs out-of-source think using your test:
IF(NOT CMAKE_BINARY_DIR STREQUAL ${CMAKE_INVOCATION_DIR} AND
CMAKE_BINARY_DIR STREQUAL ${CMAKE_SOURCE_DIR})
--
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] don't auto-clean generated files?
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 ?
Maybe an ADD_CUSTOM_TARGET() would be more suitable ?
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
Re: [CMake] FindPythonLibs should set PYTHON_INCLUDE _DIR instead of PYTHON_INCLUDE_PATH
On Monday 07 September 2009, Marcel Loose wrote: Hi all, In fact the subject line says it all. To be compliant with the naming conventions proposed in the Modules/readme.txt file, FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH. To avoid breaking existing software, it would be best to simply just add a definition for PYTHON_INCLUDE_DIR. please put it in the bug tracker, ideally together with a patch :-) 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
Re: [CMake] don't auto-clean generated files?
On Mon, Sep 7, 2009 at 1:00 PM, Alexander
Neundorfa.neundorf-w...@gmx.net 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.
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.
--
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
