Re: [CMake] Converting from autoconf to cmake problem
On Tue, Nov 2, 2010 at 12:40 AM, Michael Wild them...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi In addition to the other replies, here some thoughts on the mentioned macros (see below): On 10/30/2010 05:45 AM, mina adel wrote: Hi All I am converting a code from configure.ac to cmake. Can any one please advice me about what is the corresponding macro for the following. I have searched the cmake wiki and documentation and didnot find any. AC_HEADER_STDBOOL That one's fine, since not all compilers implement C99. AC_C_CONST This macro is marked as obsolescent: http://www.gnu.org/software/hello/manual/autoconf/C-Compiler.html#index-AC_005fC_005fCONST-885 AC_TYPE_PID_T AC_TYPE_SIZE_T Those two might be useful. AC_STRUCT_TM That one's obsolescent too: http://www.gnu.org/software/hello/manual/autoconf/Particular-Structures.html#index-AC_005fSTRUCT_005fTM-693 # Checks for library functions. AC_FUNC_CLOSEDIR_VOID Obsolescent: http://www.gnu.org/software/hello/manual/autoconf/Particular-Functions.html#index-AC_005fFUNC_005fCLOSEDIR_005fVOID-380 AC_FUNC_ERROR_AT_LINE Obsolescent, use Gnulib instead: http://www.gnu.org/software/hello/manual/autoconf/Particular-Functions.html#index-AC_005fFUNC_005fERROR_005fAT_005fLINE-385 AC_FUNC_FORK AC_FUNC_MALLOC AC_FUNC_REALLOC Could be useful too. AC_TYPE_SIGNAL I pretty much bet that you require a C89 compiler and thus this macro is also pretty much useless to you: http://www.gnu.org/software/hello/manual/autoconf/Obsolete-Macros.html#index-AC_005fTYPE_005fSIGNAL-2139 AC_FUNC_VPRINTF Obsolescent: http://www.gnu.org/software/hello/manual/autoconf/Particular-Functions.html#index-AC_005fFUNC_005fVPRINTF-546 Thank u Mina HTH Michael Michael brings up a good point and I'd take it one step further. Rather then re-creating the laundry list of Autoconf macros, I'd rather just see a few macros like: CMAKE_CHECK_C99_COMPATIBILITY CMAKE_CHECK_PLATFORM_BITS CMAKE_CHECK_POSIX_COMPATIBILITY CMAKE_CHECK_BSD_COMPATIBILITY Which are basically are best practices for checking your compiler for C99, etc and if your platform is 32 or 64 bits. These macros would provide both individual feature results and a single yes/no for each group. Ideally cmake would also provide a sample config.h template with the appropriate #cmakedefine entries. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic 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 carpe diem quam minimum credula postero ___ 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] Converting from autoconf to cmake problem
On Tue, Nov 2, 2010 at 6:09 PM, Clifford Yapp cliffy...@gmail.com wrote: On Tue, Nov 2, 2010 at 12:24 PM, Aaron Turner synfina...@gmail.com wrote: Michael brings up a good point and I'd take it one step further. Rather then re-creating the laundry list of Autoconf macros, I'd rather just see a few macros like: CMAKE_CHECK_C99_COMPATIBILITY CMAKE_CHECK_PLATFORM_BITS CMAKE_CHECK_POSIX_COMPATIBILITY CMAKE_CHECK_BSD_COMPATIBILITY Which are basically are best practices for checking your compiler for C99, etc and if your platform is 32 or 64 bits. These macros would provide both individual feature results and a single yes/no for each group. I agree those would be good ideas, but I think the way to do them is to have the individual macros (most of which will probably map to AC macros, since that's more or less what their job is) and then have parent macros along the lines of the ones you describe. This lets people do the high level calls if they want/need all of the tests for a given question, and still lets people pick and choose if they only need a subset of the full tests. That's fine. But IMHO most people would be better served just testing for C99 or C89, etc then picking and choosing. Note: I'm not saying the macro's shouldn't enumerate each feature individually, but it's easier and less error prone to group them intelligently. Remember some situations (old corporate computers that can't be replaced for policy reasons) may still have code bases that require the older tests - they should not be included by default in the above parent macros (which can just set them to their default success/fail state as appropriate), but some situations are likely to still need them. I'd say don't implement the obsolete ones unless they either already are done or there is clear demonstrated user need for them, but don't rule them out. Sure no argument there- the more canned tests the better. From an ROI perspective though, IMHO, we're better off concentrating on the newer standards and then working backwards. Ideally cmake would also provide a sample config.h template with the appropriate #cmakedefine entries. That's a possibility, but another option might be to generate the config.h.in file based on the tests - I'm doing this with BRL-CAD via some wrapper macros and it seems to be doing fine - sort of a poor man's autoheader. config.h template == config.h.in so yeah, we're saying the same thing I suspect. :) But yeah, a Cmake version of autoheader would be really nice. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic 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 carpe diem quam minimum credula postero ___ 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] Converting from autoconf to cmake problem
On Fri, Oct 29, 2010 at 8:45 PM, mina adel elecengineer_m...@yahoo.com wrote: Hi All I am converting a code from configure.ac to cmake. Can any one please advice me about what is the corresponding macro for the following. I have searched the cmake wiki and documentation and didnot find any. AC_HEADER_STDBOOL AC_C_CONST AC_TYPE_PID_T AC_TYPE_SIZE_T AC_STRUCT_TM # Checks for library functions. AC_FUNC_CLOSEDIR_VOID AC_FUNC_ERROR_AT_LINE AC_FUNC_FORK AC_FUNC_MALLOC AC_FUNC_REALLOC AC_TYPE_SIGNAL AC_FUNC_VPRINTF Read up on: check_function_exists() check_type_size() check_include_file() -- Aaron Turner http://synfin.net/ Twitter: @synfinatic 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 carpe diem quam minimum credula postero ___ 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] bash completion for cmake
Very cool Eric. Thank you for putting in the effort! On Tue, Jul 27, 2010 at 5:35 AM, Eric Noulard eric.noul...@gmail.com wrote: 2010/7/27 Eric Noulard eric.noul...@gmail.com: Here comes a proposal for a bash completion for cmake. Should work with almost any cmake version because it's using cmake command to retrieve completion. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic 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 carpe diem quam minimum credula postero ___ 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] QT4 on OSX and Cocoa
per this: http://doc.qt.nokia.com/4.6/developing-on-mac.html There is only one build, but it supports both. Unfortunately, it defaults to Carbon *unless* you pass -cocoa to qmake. And Carbon doesn't support 64bit. Since QT4/Cocoa supports 32bit 64bit it's safe to default that way; no idea why Nokia didn't choose that in the first place. Sounds like I need to hack the FindQt4.cmake package and send a patch. :) On Tue, May 4, 2010 at 6:05 AM, Michael Jackson mike.jack...@bluequartz.net wrote: Did you download a Cocoa build of Qt4 or build Qt4 with Cocoa support yourself? I don't think there is anything special to do in CMake besides the normal find_package (Qt4) stuff. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On May 4, 2010, at 12:31 AM, Aaron Turner wrote: What's the trick for getting cmake to pass -cocoa to qmake so QT4 will link against 64bit apps on Snow Leopard? The default QT4 build only supports 64bit under Cocoa, but Carbon is the default. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic 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 carpe diem quam minimum credula postero ___ 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 -- Aaron Turner http://synfin.net/ Twitter: @synfinatic 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 carpe diem quam minimum credula postero ___ 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] QT4 on OSX and Cocoa
Doh! Yeah, I suspect that will help quite a bit. :) Thanks. -Aaron On Tue, May 4, 2010 at 9:04 AM, Michael Jackson mike.jack...@bluequartz.net wrote: According to this page: http://qt.nokia.com/downloads/qt-for-open-source-cpp-development-on-mac-os-x You download EITHER the Carbon OR the Cocoa version. I think you are getting confused with actually BUILDING Qt yourself. If you do build Qt yourself then you will need to pass the -cocoa to the configure script in order to build Qt with Cocoa. You would also need to pass the proper arch flags in addition so that you build the archs that you want to support (i386, ppc, x86_64). Once Qt is built and (optionally) installed, CMake will determine which option (Carbon or Cocoa) was used when Qt was built and add the appropriate compile and linker flags to your build. Hope that helps. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On May 4, 2010, at 11:50 AM, Aaron Turner wrote: per this: http://doc.qt.nokia.com/4.6/developing-on-mac.html There is only one build, but it supports both. Unfortunately, it defaults to Carbon *unless* you pass -cocoa to qmake. And Carbon doesn't support 64bit. Since QT4/Cocoa supports 32bit 64bit it's safe to default that way; no idea why Nokia didn't choose that in the first place. Sounds like I need to hack the FindQt4.cmake package and send a patch. :) On Tue, May 4, 2010 at 6:05 AM, Michael Jackson mike.jack...@bluequartz.net wrote: Did you download a Cocoa build of Qt4 or build Qt4 with Cocoa support yourself? I don't think there is anything special to do in CMake besides the normal find_package (Qt4) stuff. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On May 4, 2010, at 12:31 AM, Aaron Turner wrote: What's the trick for getting cmake to pass -cocoa to qmake so QT4 will link against 64bit apps on Snow Leopard? The default QT4 build only supports 64bit under Cocoa, but Carbon is the default. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic 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 carpe diem quam minimum credula postero ___ 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 -- Aaron Turner http://synfin.net/ Twitter: @synfinatic 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 carpe diem quam minimum credula postero -- Aaron Turner http://synfin.net/ Twitter: @synfinatic 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 carpe diem quam minimum credula postero ___ 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] QT4 on OSX and Cocoa
What's the trick for getting cmake to pass -cocoa to qmake so QT4 will link against 64bit apps on Snow Leopard? The default QT4 build only supports 64bit under Cocoa, but Carbon is the default. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic 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 carpe diem quam minimum credula postero ___ 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
Neundorfa.neundorf-w...@gmx.net wrote:
On Tuesday 08 September 2009, Aaron Turner wrote:
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.
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 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
[CMake] don't auto-clean generated files?
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.
Suggestions?
--
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 Sun, Sep 6, 2009 at 8:09 PM, Alan W. Irwinir...@beluga.phys.uvic.ca wrote:
On 2009-09-06 17:59-0700 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.
Suggestions?
From the cmake man page, a directory property that might be useful to you is
CLEAN_NO_CUSTOM.
That actually does work... although making it global for a directory
is a bit unfortunate. Too bad this isn't per-file.
Thanks!
--
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] Invitation to connect on LinkedIn
2009/7/7 Adolfo Rodríguez dof...@gmail.com: ??? Is this an unintended mistake, the biddings of malware, or a self-publicity stunt? (or am I just not getting it :P ) Seems to happen all the time on lists. People import all their contacts into LinkedIn, etc and invite them all without bothering to take the few minutes to remove any mailing lists or other inappropriate addresses. So no malice, just people being lazy. -- 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] linking cmake targets to cpack targets
On Fri, Feb 27, 2009 at 7:36 AM, Eric Noulard eric.noul...@gmail.com wrote:
2009/2/27 Aaron Turner synfina...@gmail.com:
When I was using autotools, I'd hook up a target version to
dist-gzip so that my version.c (which was auto-generated and had my
svn repo revision in it) was always up to date when I built my source
tarball. Is there a way to do that with cpack's package_source
target?
Doing the obvious:
add_dependencies(package_source version)
Doesn't work since I'm guessing package_source is another one of those
fake targets.
Yes I think this is worth a feature request regarding
how to add_dependencies on builtin target
(install, package_source, package, etc)
Unfortunately, since package_source doesn't depend on
the ALL target, I can't hook it up that way nor does there seem to be
anything like a CPACK_SOURCE_INCLUDE_FILES (which would be the
opposite of CPACK_SOURCE_IGNORE_FILES).
A possible way to do what you want is to create
your own
package_source_cleanly target
with something like:
ADD_CUSTOM_TARGET(package_source_cleanly
COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/PackageSourceCleanly.cmake
)
The PackageSourceCleanly.cmake file is your custom CMake script, which
may force an extra CMake execution before calling cpack itself, for example:
MESSAGE(STATUS Enforce CMake re-run...)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} .
TIMEOUT 3600
WORKING_DIRECTORY ${CMAKE_BINARY_DIR})
MESSAGE(STATUS Enforce CMake re-run...Done.)
MESSAGE(STATUS Package Source running cpack...)
EXECUTE_PROCESS(COMMAND cpack -G TGZ --config CPackSourceConfig.cmake
TIMEOUT 3600
WORKING_DIRECTORY ${CMAKE_BINARY_DIR})
MESSAGE(STATUS Copy ${CPACK_SOURCE_PACKAGE_FILE_NAME}.tar.gz --
${CPACK_SOURCE_PACKAGE_FILE_NAME}-${WHO_OUT}-${DATE_OUT}.tar.gz)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E copy
${CPACK_SOURCE_PACKAGE_FILE_NAME}.tar.gz
${CPACK_SOURCE_PACKAGE_FILE_NAME}-clean.tar.gz)
MESSAGE(STATUS Package backup done in:
${CPACK_SOURCE_PACKAGE_FILE_NAME}-clean.tar.gz)
I do use this kind of trick for building dated package backup.
see
http://www.cmake.org/pipermail/cmake/2008-November/025246.html
You'll find a modified version of the scripts sent by Ioan at that time.
So is there a clean way to pass the current Cmake config variables to
a new cmake process via execute_process()? Or do I need to create a
template file and use configure_file() to do that? Basically, your
above example doesn't work for me because things like
${CPACK_SOURCE_PACKAGE_FILE_NAME} are undefined.
--
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
[CMake] linking cmake targets to cpack targets
When I was using autotools, I'd hook up a target version to dist-gzip so that my version.c (which was auto-generated and had my svn repo revision in it) was always up to date when I built my source tarball. Is there a way to do that with cpack's package_source target? Doing the obvious: add_dependencies(package_source version) Doesn't work since I'm guessing package_source is another one of those fake targets. Unfortunately, since package_source doesn't depend on the ALL target, I can't hook it up that way nor does there seem to be anything like a CPACK_SOURCE_INCLUDE_FILES (which would be the opposite of CPACK_SOURCE_IGNORE_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] CMake ML searchable archive added to the FAQ
On Sat, Feb 21, 2009 at 3:45 AM, Eric Noulard eric.noul...@gmail.com wrote: Hi All, I have just added to the FAQ a question: Where can I find searchable CMake Mailing Archives? with current answer: * http://www.mail-archive.com/cmake@cmake.org/ * http://marc.info/?l=cmake I did update: http://www.cmake.org/Wiki/CMake#Primary_Resources_-_Look_here_first.21 too I hope this would make it easier for everybody to search in the CMake community knowledge :-) PS: feel free to update the answer in the FAQ if you know more searchable archives of the ML. I've always used the site keyword via google to search the archives: site:http://www.cmake.org/pipermail/cmake/ search terms Owner of the archives could also Google Custom Search (http://www.google.com/coop/cse/) to add a search box to the archive templates. -- 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
[CMake] functions custom commands- what's the trick?
sample code to illustrate problem:
cmake_minimum_required(VERSION 2.6)
function(clean_standard_files)
message(STATUS running clean_standard_files)
endfunction(clean_standard_files)
add_custom_target(standard)
add_custom_command(TARGET standard
COMMAND clean_standard_files
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
VERBATIM)
then running 'make standard' doesn't work:
make[3]: clean_standard_files: Command not found
make[3]: *** [standard] Error 127
make[2]: *** [CMakeFiles/standard.dir/all] Error 2
make[1]: *** [CMakeFiles/standard.dir/rule] Error 2
I seem to be missing something painfully obvious, but I'm not sure what.
--
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] functions custom commands- what's the trick?
On Fri, Feb 20, 2009 at 9:25 AM, Mathieu Malaterre
mathieu.malate...@gmail.com wrote:
On Fri, Feb 20, 2009 at 6:14 PM, Mike Arthur m...@mikearthur.co.uk wrote:
On Friday 20 February 2009 08:22:59 Aaron Turner wrote:
I seem to be missing something painfully obvious, but I'm not sure what.
You don't enter it into add_custom_command, that's for shell commands., just
enter clean_standard_files() into your CMakeLists.
You can't run CMake functions at Make time though, only CMake time (which
will only be called to first generate or if the CMake files have changed).
Just to avoid any confusion... you can but you have to use the script
mode: cmake -P
Thanks Mathieu! That's a very useful trick.
Also, I'd like to suggest someone modify the online docs for
execute_process() to mention that:
set(args -i foo -b bar)
execute_process(COMMAND cmd ${args})
is NOT valid. You need to do:
set(args -i foo -b bar)
separate_arguments(args)
execute_process(COMMAND cmd ${args})
I only figured that out after much pain suffering.
--
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] creating custom make targets
On Thu, Feb 19, 2009 at 8:29 AM, Matthew Woehlke mw_tr...@users.sourceforge.net wrote: Aaron Turner wrote: From the docs, it sounded like this only worked when adding commands to existing targets, not for creating new ones. Correct, as Eric already pointed out. You need to create the target first with add_custom_target. Ok, that just seemed weird since it seemed like add_custom_target() was always built. After more carefully reading the docs, I see that it's just always out of date, but that's not the same as automatically created as a dependency of 'all'. My testing though seems to show that the correct usage is actually: add_custom_command(foo ...) if you use: add_custom_command(TARGET foo ...) then the target name (verified by 'make help') is called TARGET, not foo That's... interesting. The doc says: add_custom_command(TARGET target PRE_BUILD | PRE_LINK | POST_BUILD COMMAND command1 [ARGS] [args1...] [COMMAND command2 [ARGS] [args2...] ...] [WORKING_DIRECTORY dir] [COMMENT comment] [VERBATIM]) ...but that's creating a target named TARGET? If so it would seem to be a bug (either in cmake or in the doc; either way it would be good if you could confirm this, and if it isn't working according to the doc, file a bug report). Whoops, my bad. Typed add_custom_target not add_custom_command. Thanks everyone, this makes sense now. -- 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] 64bit linking on linux
On Wed, Feb 18, 2009 at 6:52 AM, Bill Hoffman bill.hoff...@kitware.com wrote: Birju Prajapati wrote: I've figured it out. I added the following lines into the root CMakeLists.txt file: SET(CMAKE_CXX_FLAGS -m64) SET(CMAKE_C_FLAGS -m64) SET(CMAKE_EXE_LINKER_FLAGS -m64) SET(CMAKE_MODULE_LINKER_FLAGS -m64) SET(CMAKE_SHARED_LINKER_FLAGS -m64) That is not the preferable way to do this. As it hard codes flags into the CMake file. The way I would do it is: export CXXFLAGS=-m64 export CFLAGS=-m64 export LDFLAGS=-m64 cmake ../myproject If those environment variables are set BEFORE you run cmake, then cmake will put them into the cache correctly. Couldn't you use the check_c_source_runs() macro to test if your system supports the -m64 flag? That way you wouldn't need to require the user to specify it (always fraught with peril). -- 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
[CMake] creating custom make targets
No, this isn't create_custom_target- this is a generic target (non-executable) that should only be built when the user specifies it explicitly. Basically, I have a bunch of unit tests (which want to convert to CTest framework). Each of these tests executes a command and compares it's output to a pre-determined result. A simple diff command determines pass/fail. Creating these pre-determined outputs is currently done via running: make test_standard Obviously, I don't want these test cases built each time I build, and re-running cmake to specify an config var to do this would technically work, but be annoying. Basically, I'm looking for a way to create a new make target test_standard and associate create_custom_target()'s to it. Suggestions? -- 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] open source project for CMake ports?
Trying to get up to speed on this thread- apologies if I missed this. Long story short, as an OSS developer and new Cmake user, I'm less interested in getting libfoo building with Cmake and a lot more interested in CMake modules for detecting and using libfoo in my own project. In reality, these are very much interrelated, but let me explain A lot of the things I take for granted in Autotools requires me to roll my own in Cmake; which when you have a number of dependencies is daunting when you consider all the issues with different platforms library versions. I think this is one of the biggest roadblocks for people to switch to Cmake- knowing that they're leaving behind years of tribal knowledge which has been created in Autoconf scripts. If there was an equivalent of the Autoconf Macro Archive (http://autoconf-archive.cryp.to/) for Cmake, which was a collection of common tests I think that would help a great deal. Obviously, Cmake already includes some of these sorts of tests for GUI toolkits and libraries of that nature, but obviously there are a lot of obvious holes in the list (gmp, pcre, (win)pcap, etc). Also there are a number of system capability tests missing like checking for strictly aligned memory. I'm currently having to write modules for a number of these cases and it's a lot of work. Honestly, it is more work then just porting my code from Autotools to Cmake because I'm already an expert on my code and how it compiles- trying to become an expert on these other libraries and systems is a lot more effort. Honestly, I think in the long run, improving the existing standard library of Cmake modules to allow developers to concentrate on how to build their own code rather then figure out how to link to various libraries and write portability tests will win grow the Cmake user base much faster. -- 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
[CMake] CheckTypeSize and non-standard headers
I'm trying to figure out how to write my CMakeLists.txt file to find wint_t under OSX which defines it in /usr/include/runetype.h rather then one of the standard headers that CheckTypeSize uses. I was hoping Cmake behaved like autotools where if you first look for the header it will automatically include it in future type checks, but that doesn't seem to be the case. Suggestions? -- 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] CheckTypeSize and non-standard headers
On Mon, Feb 16, 2009 at 12:14 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
SET(CMAKE_REQUIRED_INCLUDES_SAVE ${CMAKE_REQUIRED_INCLUDES})
SET(CMAKE_REQUIRED_INCLUDES ${CMAKE_REQUIRED_INCLUDES};/usr/include)
CHECK_SYMBOL_EXISTS(wint_t runetype.h HAVE_WINT_T)
SET(CMAKE_REQUIRED_INCLUDES ${CMAKE_REQUIRED_INCLUDES_SAVE})
IF (HAVE_WINT_T)
message(STATUS wint_t is available)
endif()
Doesn't seem to work. FYI:
echo '#include runetype.h' | gcc -E - | grep wint_t
returns:
typedef int __darwin_wint_t;
typedef __darwin_wint_t wint_t;
So I know I'm using the right header. this is cmake 2.6-patch 2
--
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] CheckTypeSize and non-standard headers
More testing seems to indicate that check_symbol_exists won't find any
typedef defined in headers.
Looking a the CheckSymbolExists.cmake file, the following .c is
generated as a test:
#include runetype.h
void cmakeRequireSymbol(int dummy,...) {
(void)dummy;
}
int main() {
#ifndef wint_t
cmakeRequireSymbol(0, wint_t);
#endif
return 0;
}
Unfortunately, you can't use #ifndef to test for the existence of a
typedef, hence you get a compile failure and the result of the test is
false.
Is there another check which is typedef/define agnostic? I'm sure I
could write my own, but this seems like it should be included in the
standard cmake library.
--
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] CheckTypeSize and non-standard headers
On Mon, Feb 16, 2009 at 9:28 PM, Philip Lowman phi...@yhbt.com wrote:
On Mon, Feb 16, 2009 at 10:23 PM, Aaron Turner synfina...@gmail.com wrote:
On Mon, Feb 16, 2009 at 5:53 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
project(Test)
cmake_minimum_required(VERSION 2.7)
INCLUDE(${CMAKE_ROOT}/Modules/CheckTypeSize.cmake)
set(CMAKE_REQUIRED_DEFINITIONS_SAVE ${CMAKE_REQUIRED_DEFINITIONS})
set(CMAKE_REQUIRED_DEFINITIONS
${CMAKE_REQUIRED_DEFINITIONS};-D__need_wint_t=1)
CHECK_TYPE_SIZE(wint_t WINT_T)
message(STATUS Size of wint_t: ${WINT_T})
message(STATUS HAVE_WINT_T: ${HAVE_WINT_T})
set(CMAKE_REQUIRED_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS_SAVE})
Although I am not sure under what circumstances you are supposed to
define
__need_wint_t? Or if there is some other encompassing macro to define.
Otherwise the above will find the size in bytes of wint_t.
Not sure I follow what you're trying to accomplish with the above.
Is this cmake 2.7 specific or some trick with the __need_wint_t (which
isn't used in runetype.h)?
Hmm, try it in CMake 2.6, there is a CheckTypeSize.cmake. Also, you
shouldn't have to specify the full path to it, just
INCLUDE(CheckTypeSize.cmake)
As I said in my first post, CheckTypeSize doesn't include runetype.h,
hence doesn't work in this case.
For now, i'm just hacking around the issue with:
check_include_file(runetype.h HAVE_RUNETYPE_H)
IF(APPLE AND HAVE_RUNETYPE_H)
# OS X has wint_t, but check_type_size won't find it
SET(HAVE_WINT_T 1)
ELSE(APPLE AND HAVE_RUNETYPE_H)
check_type_size(wint_tHAVE_WINT_T)
ENDIF(APPLE AND HAVE_RUNTYPE_H)
Long term, I'm going to write my own version of check_symbol_exists
which uses a different test which is define/typedef agnostic.
Please consider submitting it via the bugtracker when you're done.
Will do. Honestly, I'm a bit surprised this isn't already part of the
basic Cmake library. Having to write try_compile() or try_run() tests
for this sort of thing is just silly- especially since you can't
inline the source code like in Autoconf.
--
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] CheckTypeSize and non-standard headers
On Mon, Feb 16, 2009 at 9:53 PM, Philip Lowman phi...@yhbt.com wrote:
On Tue, Feb 17, 2009 at 12:41 AM, Aaron Turner synfina...@gmail.com wrote:
On Mon, Feb 16, 2009 at 9:28 PM, Philip Lowman phi...@yhbt.com wrote:
On Mon, Feb 16, 2009 at 10:23 PM, Aaron Turner synfina...@gmail.com
wrote:
For now, i'm just hacking around the issue with:
check_include_file(runetype.h HAVE_RUNETYPE_H)
IF(APPLE AND HAVE_RUNETYPE_H)
# OS X has wint_t, but check_type_size won't find it
SET(HAVE_WINT_T 1)
ELSE(APPLE AND HAVE_RUNETYPE_H)
check_type_size(wint_tHAVE_WINT_T)
ENDIF(APPLE AND HAVE_RUNTYPE_H)
Long term, I'm going to write my own version of check_symbol_exists
which uses a different test which is define/typedef agnostic.
Please consider submitting it via the bugtracker when you're done.
Will do. Honestly, I'm a bit surprised this isn't already part of the
basic Cmake library. Having to write try_compile() or try_run() tests
for this sort of thing is just silly- especially since you can't
inline the source code like in Autoconf.
Not sure on the check_symbol_exists issue.
You should be able to inline source code in your CMakeLists.txt. Here's an
example I wrote for OpenSceneGraph:
INCLUDE(CheckCXXSourceCompiles)
SET(CMAKE_REQUIRED_DEFINITIONS -DGLU_TESS_CALLBACK_TRIPLEDOT)
SET(CMAKE_REQUIRED_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/include
${GLUT_INCLUDE_DIR} ${GL_INCLUDE_DIR})
SET(CMAKE_REQUIRED_LIBRARIES ${GLUT_LIBRARY} ${GL_LIBRARY})
CHECK_CXX_SOURCE_COMPILES(
#include osg/GL
#include osg/GLU
static void testcb(GLvoid *, void*) { }
int main() {
GLUtesselator *t = gluNewTess();
gluTessCallback(t, GLU_TESS_VERTEX_DATA, (GLU_TESS_CALLBACK)
testcb);
return 0;
}
GLU_Tesselator_Needs_Variable_Parameter_Callback_Convention_Failure_Means_No)
SET(DEFAULT_GLU_TESS_CALLBACK_TRIPLEDOT
${GLU_Tesselator_Needs_Variable_Parameter_Callback_Convention_Failure_Means_No})
Ah! I hadn't noticed CheckCSourceCompiles/Runs... that makes things
easier! thanks.
--
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] Adding install dependency to test-target?
On Fri, Jan 30, 2009 at 3:00 AM, Hugo Heden hugohe...@gmail.com wrote:
Try using quotes:
SET_DIRECTORY_PROPERTIES(PROPERTIES
ADDITIONAL_MAKE_CLEAN_FILES ${extra_libopts_clean_files} )
Thanks! That solved my problem.
And
If I specify each file individually, it appears that only the last
takes effect (basically subsequent calls overwrite the previous
value). Surely there is a way to specify multiple files right?
In such a case, you could use the APPEND functionality in set_property:
http://www.cmake.org/cmake/help/ctest2.6docs.html#command:set_property
SET_PROPERTY(
DIRECTORY ${CMAKE_CURRENT_SOURCE_DIRECTORY}
APPEND
ADDITIONAL_MAKE_CLEAN_FILES ./libopts/.libs/libopts.la
)
But beware of this issue when using ADDITIONAL_MAKE_CLEAN_FILES
http://public.kitware.com/Bug/view.php?id=8164
-- if there is no *target* present in the CMakeLists.txt, then the
directory does not count as a directory in the cmake sense, so the
directory property will be ignored.
Thanks for the warning. In my case my work around of using the path
to the directory of the file and placing the cmake commands in the
parent directory seems to be working.
--
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
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding install dependency to test-target?
On Thu, Jan 29, 2009 at 7:43 AM, Hugo Heden hugohe...@gmail.com wrote:
2008/11/20 Eric Noulard eric.noul...@gmail.com:
2008/11/20 Hugo Heden he...@foi.se:
Good day all,
Is there any way that I can add 'install' dependency to the 'test'-target?
Doing
add_dependencies( test install )
does not seem to work:
CMake Error at ... (ADD_DEPENDENCIES):
add_dependencies Adding dependency to non-existent target: test
I don't think it's possible to add dependencies to built-in CMake target
(which deserve a feature request :-)
Apparently neither 'test' nor 'install' counts as top-level-targets?
Precisely :=)
Feature request added: http://public.kitware.com/Bug/view.php?id=8438
Sorry to hijack the thread, but I believe I'm having the same issue
with the target clean:
ADD_CUSTOM_TARGET(clean_libopts
COMMAND ${MAKE} clean
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}/libopts)
ADD_DEPENDENCIES(clean clean_libopts)
results in:
CMake Error at CMakeLists.txt:245 (ADD_DEPENDENCIES):
add_dependencies Adding dependency to non-existent target: clean
I'm doing the above because libopts is not built via cmake, but via autotools.
--
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
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding install dependency to test-target?
On Thu, Jan 29, 2009 at 12:37 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
Yes, that doesn't work. clean, all, install are a special kind of target
in cmake, i.e. they are not really targets, they are only created when the
project files/makefiles are written.
You could add a second COMMAND to the clean_libopts target, which does a make
clean for the current cmake project (yes, that's more a workaround).
Yeah I may end up having to do that... really annoying. Right now,
I'm trying to figure out how to use ADDITIONAL_MAKE_CLEAN_FILES.
If I do this:
LIST(APPEND extra_libopts_clean_files
./libopts/.libs/libopts.o
./libopts/.libs/libopts.la
./libopts/.libs
./libopts/_libs
./libopts/libopts.la
./libopts/so_locations
./libopts/*.o
./libopts/*.lo
)
SET_DIRECTORY_PROPERTIES(PROPERTIES
ADDITIONAL_MAKE_CLEAN_FILES ${extra_libopts_clean_files})
I get an error about too many args to SET_DIRECTORY_PROPERTIES. And
If I specify each file individually, it appears that only the last
takes effect (basically subsequent calls overwrite the previous
value). Surely there is a way to specify multiple files right?
Honestly, both of these solutions are just hacks it seems like
cmake really should have a way to add to the 'clean' and 'install'
pseudo-targets.
--
--
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
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
