[CMake] Build tree with common dependency - CMP-0002
Hello all,
I've been working on getting cmake set up in our dev environment for cross
platform builds and am running into some (one, primarily) issues.
In general, our source tree looks like this:
project Folder A
\
code folder for (static lib) project A-1
|
code folder for (static lib) project A-2
|
code folder for (dynamic lib) project A-3
project Folder B
\
code folder for (static lib) project B-1
|
code folder for (static lib) project B-2
|
code folder for (static lib) project B-3
project Folder C
\
code folder for (dynamic lib) project C-1
|
code folder for (dynamic lib) project C-2
|
code folder for (static lib) project C-3
The problem - dependencies. Each build is supposed to be independent of any
other. S:
Build Project A-1
\
Depends on B-1
\
Depends on C-3
Build Project A-2
\
Depends on B-3
\
Depends on C-3
Build Project A-3
\
Depends on A-1
\
Depends on A-2
I cannot figure out how to prevent CMP-0002 errors on target C-3 when trying to
build A-3 (without first having to run a separate build of C-3 prior to running
any of them).
Here is a snippet of how I am loading the C-3 library in B-1 and B-3:
find_library(PLATFORM_LIB Platform
${CMAKE_BINARY_DIR}/../lib/$ENV{PLATFORM_NAME} )
if (NOT EXISTS ${PLATFORM_LIB})
message(STATUS "Platform library does not exist. Adding source build.")
add_subdirectory( ${CMAKE_BINARY_DIR}/../source/n2ksdk/platform
${CMAKE_BINARY_DIR}/../buildPlatform )
endif (NOT EXISTS ${PLATFORM_LIB})
Any help or guidance would be appreciated.
Regards,
Frank
___
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] Virtual Studio 8 and 10 error: '/Tc' requires an argument
I have my CMake build, test and install working on Linux, and now I'm trying to get it to build on Windows. On Windows XP SP3, I have installed: CMake 2.8.2 Virtual Studio Express 9 and 10 CMake Configure and Generate for either Virtual Studio 9 or 10 run without error. In VS, I open the project or solution, and execute the VS "Build > Build BUILD_ALL" command. The cl compiler fails with the error, -- Build started: Project: dp42, Configuration: Debug Win32 -- Compiling... cl : Command line error D8004 : '/Tc' requires an argument The same thing happens when I generate for and build on VS 9 and 10. What is the problem here? ___ 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] Small, complete CPack example?
On 8/5/10 6:22 PM, Eric Noulard wrote: > 2010/8/6 Chris Wolf : >> >> Unfortunately, at first, I din't see how your example is different from >> the parts of my CMakeList.txt I sent in my last post. >> >> Then I noticed that your "install(TARGETS..." command had a relative >> path for "DESTINATION", whereas mine had an absolute path. When >> I changed to a relative path, it worked... > > You should really avoid using absolute path destination for installation. > > If you cannot avoid it then you should tell CPack to use DESTDIR > set(CPACK_SET_DESTDIR ON) > > however this comes with some trouble too, > see:http://public.kitware.com/Bug/view.php?id=7000 > > Yes, but since this is my first day with CMake, I thought I was keeping things simple by using an absolute path, to avoid uncertainty as to where things were being installed. Naturally, and as you suggest, absolute paths are inflexible for a finished product. Some other observations: The CPack-generated tar archive saves the artifact (a shared library, in my case) prefixed by the relative directory specified in install(TARGETS...), which, in turn, is again prefixed by a directory named by the projectname + "-0.1.1" + platformname. e.g for : install(TARGETS usb LIBRARY DESTINATION lib) (where project name is "libusb") The CPack-generated TGZ archive will contain: libusb-0.1.1-Darwin/lib/libusb.dylib ...this, regardless of the setting of CPACK_INCLUDE_TOPLEVEL_DIRECTORY! (I would have expected set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 0) to result in the archive to contain: ./lib/libusb.dylib) Another observation regarding the CPack-generated *.pkg (wrapped in a *.dmg) : The path is prefixed by "./usr", somehow: (assuming the *.dmg is already mounted) $ cd ./libusb-0.1.1-Darwin.pkg/Contents $ lsbom -s Archive.bom . ./usr ./usr/lib ./usr/lib/libusb.dylib So where does the "./usr/" prefix come from? Thanks, Chris Wolf ___ 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] Support for multiple components in cpack
2010/8/4 Kishore : > On Monday 02 Aug 2010 4:59:47 pm Eric Noulard wrote: >> Hi All, >> >> I did add a patch for the "multiple file problem" >> http://public.kitware.com/Bug/view.php?id=10736 >> >> May be interested people can have a try and comment >> this patch. >> >> It adds the possibility for any CPack generators to generate multiple >> file. It adds "preliminary" support for component to all "Archive >> Generators" (ZIP, TGZ, STGZ etc...) as an example of use. >> >> The change is "backward compatible" in the sense that if >> all CPack generators (but the archive one) behaves as before >> with either componentized project or not. >> >> Waiting for feedback before going on > > Thanks. It just tried this and it works as claimed. Later today, i will > inspect the generated packages on a windows machine too. Do you have feedback on WIndows? > Ps: Excited, I tried building a DEB package with this patch thinking that it > would result in multiple packages. I then reread the post and consoled myself > that although DEB is also really an archive... the patch does not work on it! DEB (or RPM) support is not done yet. I'd like to reach a consensus and approval on ArchiveGenerator before going on with other generators. I would accept testing patch too :-) -- 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] [cmake-developers] Support for multiple components in cpack
2010/8/3 Eric Noulard : > 2010/8/3 David Cole : >> On Mon, Aug 2, 2010 at 6:57 PM, Eric Noulard wrote: > >>> >>> 2. may always be an option because it was the behavior we had before the >>> component support and ALL CPack generator may handle an all-in-one >>> package. >>> We could add an OPTION like CPACK_COMPONENT_ALL_IN_ONE which >>> would basically tell CPack to ignore the component aspect. >> >> FYI: there already is an option that's similar to this, I >> think: CPACK_MONOLITHIC_INSTALL >> Does that have the effect you're talking about or are you thinking something >> different? > > You are right that's the idea. > I wasn't aware of that option... I'll go for a thorough read of > CPack.cmake documentation > before re-inventing existing options... After a remark made by Clint and some thought. CPACK_MONOLITHIC_INSTALL is not covering the whole need and I think we need a CPACK_COMPONENTS_ALL_GROUPS_IN_ONE_PACKAGE options. Have a look at the updated bug entry and the description of all cases: http://public.kitware.com/Bug/view.php?id=10736 There is a fifth patch to the current patchset to propose that. Clint would you be able to give it a try and tell us if with this last patch (still cumulative) your needs are covered? -- 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] How to obtain "date of the day"
Hi All,
I wrote a little c++ program that gets the date and time from the
system. It just returns a UTC time: "/mm/dd hhm:ss UTC". Works in
Linux, Windows, MAC-OS but does use iostream and ctime.
Then I have this in my CMake file:
#-
# Determine a build date.
# Get the build date
try_run(TEST_DID_RUN TEST_DID_COMPILE "${CMAKE_BINARY_DIR}"
"${CMAKE_FILE_DIR}/date_time.cpp" OUTPUT_VARIABLE TEST_BUILD_DATE)
if(TEST_DID_COMPILE)
string(REGEX MATCH "[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9]
[0-9][0-9]:[0-9][0-9]:[0-9][0-9] [A-Z][A-Z][A-Z]"
CMAKE_FILE_TRANSFER_BUILD_DATE "${TEST_BUILD_DATE}")
else(TEST_DID_COMPILE)
set(CMAKE_FILE_TRANSFER_BUILD_DATE "ERROR")
endif(TEST_DID_COMPILE)
Would this be of use?
Regards
Andrew
On Fri, Aug 6, 2010 at 12:03 AM, David Cole wrote:
> On Thu, Aug 5, 2010 at 9:46 AM, Jean-Christophe Fillion-Robin
> wrote:
>>
>> hi Folks,
>>
>> Earlier in the day, somebody asked me how he could obtain "today date"
>> using cmake.
>> I replied there was no direct way to obtain the date and I told him to use
>> a macro I wrote.
>> See
>> http://viewvc.slicer.org/viewcvs.cgi/trunk/CMake/Slicer3TodayMacro.cmake?rev=11898&view=log
>>
>> Is there a better a way to retrieve "today date" ?
>
>
> Not yet. But it would be a relatively easy feature to add to CMake if
> somebody wants to sponsor it.
> I envision a new cmake command, or an extension to an existing command (like
> string with a NOW or NOW_UTC arg...) that returns a complete timestamp
> string (something like "2010-08-04 14:00:44.235675 UTC") and/or the
> components of such a string as a cmake list ("2010;8;4;14;0;44;235675;UTC").
> Any sponsors out there? :-)
>
> David
>
>>
>> Thks
>> Jc
>>
>> --
>> Phone: 1-518-836-2174
>> Ext: 304
>>
>> ___
>> 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
>
--
___
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney 2006 NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___
___
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] Small, complete CPack example?
2010/8/6 Chris Wolf : > > Unfortunately, at first, I din't see how your example is different from > the parts of my CMakeList.txt I sent in my last post. > > Then I noticed that your "install(TARGETS..." command had a relative > path for "DESTINATION", whereas mine had an absolute path. When > I changed to a relative path, it worked... You should really avoid using absolute path destination for installation. If you cannot avoid it then you should tell CPack to use DESTDIR set(CPACK_SET_DESTDIR ON) however this comes with some trouble too, see:http://public.kitware.com/Bug/view.php?id=7000 -- 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] Building source RPMs?
2010/8/5 Alexander Neundorf :
> On Thursday 05 August 2010, Magnus Therning wrote:
>> On Thu, Aug 5, 2010 at 10:39, Eric Noulard wrote:
> ...
>> > What is your usage pattern?
>>
>> We ship most of our sources as source RPMs since most of our changes are
>> added patches to upstream (CentOS) RPMs.
>>
>> It is just nice to also ship the source of our own code as RPMs rather than
>> as tar-ball. However, I don't see a big problem with simply dropping use
>> of CPack and writing the SPEC files manually. It would just be a
>> nice-to-have is all.
>
> Somehow I don't really understand how a source RPM or source deb generator
> would make sense for CPack.
> E.g. a source deb is the plain source package, plus an optional patch, plus a
> file which describes how to build it.
Yes a complete RPM spec file which may be used both for binary and source
RPM describes just that, a plain tar file, may be a bunch of patch files, then
some rules to build and install from source
(from the tar which will be automagically patched by rpmbuild).
You are right when you say that it does not make much sense to build
a source RPM with CPack but CPack is able to build a source tarball/zip etc...
CPack is able to build a binary RPM, thus
people expect it can build a source RPM too.
In fact CPack does "part of the job" of any "package build tool" like
the rpm/rpmbuild command or dpkg- commands.
> IMO the patch would be always non-existent if generated with CPack (since this
> generates the package directly from the original source tree),
You can perfectly imagine that you use upstream source tree +
separates patchsets (in Your own source tree)
and use CMake+CPack to build the whoel thing.
It seems to be the case described by Magnus.
However even if the patch set is non-existent it can be useful to have
a source rpm,
but keep reading.
> so the only thing left would be to generate the spec file.
Yes that's true but I think that for many people not writing their spec files
(or deb control data) is of great interest.
> I guess for a source RPM it's similar ?
Yes it is.
The thing is with a source RPM the user (who get the source RPM)
can rebuild a binary rpm using:
rpmbuild --rebuild your.src.rpm
it doesn't have to know whether if the software is using CMake or configure
or whatever to build. All this should be specified in the [source] spec file.
this type of action will
1) unpack the content of the source rpm
2) untar + patch the sources
3) configure the source for building (may be with cmake or configure)
4) build (make)
5) install (make install)
6) build the binary RPM by packing
So generating a "source spec file" that would be usable to build
a source package is definitely possible. In fact this was done
by the UseRPMTools.cmake
http://www.cmake.org/Wiki/images/9/94/UseRPMTools.cmake
look at ADD_CUSTOM_TARGET(${RPMNAME}_srpm rule.
But again you are right this cpack done with a cpack generator
the rule was only using cpack to build the source tarball.
The main difference between CPack and rpm/deb tools is that CPack
does know the difference between "source" and "binary" package.
The "package_source" rule is "just":
cpack --config CPackSourceConfig.cmake
and the CPackSourceConfig.cmake is using
"CPACK_INSTALLED_DIRECTORIES"
but not
"CPACK_INSTALL_CMAKE_PROJECTS"
whereas "package" is:
cpack --config CPackConfig.cmake
and CPackConfig.cmake is using
"CPACK_INSTALL_CMAKE_PROJECTS"
and not
"CPACK_INSTALLED_DIRECTORIES"
so you MUST have TWO differents "CPack config file" for describing
how to pack binary or sources. This is not the case for RPM
the spec file (i.e. RPM config file) is/may be the same for source or
binary RPM.
So if you continue to follow me until the end,
it would make sense for CPack to build a source RPM either if
CPack has knowledge that it has to build a source package or
if we write a "separate" generator whose purpose is to build the source package
something like a CPackSRPM.
Would it be worth the needed work to do it, I don't know :-)
--
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] Small, complete CPack example?
On 8/5/10 5:15 PM, Olaf van der Spek wrote: > On Thu, Aug 5, 2010 at 11:06 PM, Chris Wolf wrote: >> I'm looking all over for an end-to-end basic example of using CPack >> to create a package with a single shared library target. It can >> even be with the TGZ generator. > > cmake_minimum_required(VERSION 2.4) > set(CMAKE_BUILD_TYPE release) > include_directories(.) > add_library( > xbt SHARED > sql/database.cpp > sql/sql_query.cpp > sql/sql_result.cpp > ) > install(DIRECTORY xbt DESTINATION include FILES_MATCHING PATTERN *.h > PATTERN .svn EXCLUDE) > install(TARGETS xbt DESTINATION lib) > Ok, that worked (after I added "include(CPack)") - thanks for that. Unfortunately, at first, I din't see how your example is different from the parts of my CMakeList.txt I sent in my last post. Then I noticed that your "install(TARGETS..." command had a relative path for "DESTINATION", whereas mine had an absolute path. When I changed to a relative path, it worked... Thanks for the help! P.S. this CMake is a dream (even with my one day experience) compared to autoconf/libtool, etc. ___ 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] Dependency bug in cmake with a custom-command
On 05.08.10 17:05:46, David Cole wrote: > On Thu, Aug 5, 2010 at 2:29 PM, Andreas Pakulat wrote: > > we're currently hitting what looks like a dependency problem with CMake > > and a custom-command. Unfortunately I couldn't reproduce this so far > > with a small example and it also only happens with one of the targets > > we're building in kdevplatform. This code was recently added, but looks > > the same as another plugin cmake-code and cpp-code wise. > > > > Ok, so here's the deal: We're using a KDE macro to run Qt's uic on our > > .ui files and add the generated header filename into a cmake variable. > > This cmake variable is then passed onto a add_library call (through > > another macro). Now when running make in a freshly created builddir > > using -j3 or so, the rule for generating the ui_xxx.h header is not > > executed before trying to compile the file that uses the header... > > > > I'm using CMake 2.8.2 here currently (or rather current HEAD of the > > release branch) > > > > This problem is only reproduceable after a make clean, once I hit the > > error and do another make -j3 run, the dependencies are proper and hence > > the generation is done. > > > > I've noticed that after the first failing run the depend.make and > > depend.internal files suddenly exist/have content. So it seems that > > cmake generates this info 'too late' and hence doesn't generate the > > ui-header early enough. Whats a bit strange though is that apparently in > > other plugins this stuff works. > > > > One more info: I'm seeing the 'Scanning dependencies of target > > kdevpatchreview' message a lot later than the error when using -k with > > make. And at that point I also see the 'Generating ui_xxx.h' message. > > So, you say it "looks the same" as other plugins that do not demonstrate the > problem... but there must be some differences. > > What are the differences? Sure, this is the plugin that breaks: http://gitorious.org/kdevelop/kdevplatform/blobs/master/plugins/reviewboard/CMakeLists.txt These two seem to work fine (but that might also just be by accident because they happen to be compiled 'later' and hence their dependency scanning was done already): http://gitorious.org/kdevelop/kdevplatform/blobs/master/plugins/projectmanagerview/CMakeLists.txt http://gitorious.org/kdevelop/kdevplatform/blobs/master/plugins/subversion/CMakeLists.txt > There are lots of folks doing Qt stuff with CMake, and I do not recall > hearing of anything like this recently. I'd think it should work, so there > must be some small difference in your CMakeLists.txt file (or something it > includes) that is triggering this issue. The plugins are all on the same 'level', adding CMAKE_CURRENT_BINARY_DIR to the include_directories didn't help. > Let us know more details... easier to help when looking at code or cmake > output. I'm attaching the make-log, verbose version would probably need uploading somewhere (let me know if you'd like to see that). As I said, if I run make with -k I later on see the dependency-scanning for the kdevreviewboard target and immediately afterwards the generation of the ui_reviewpatch.h file. Andreas -- Fine day to work off excess energy. Steal something heavy. log.gz Description: Binary data ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Small, complete CPack example?
On Thu, Aug 5, 2010 at 11:06 PM, Chris Wolf wrote: > I'm looking all over for an end-to-end basic example of using CPack > to create a package with a single shared library target. It can > even be with the TGZ generator. cmake_minimum_required(VERSION 2.4) set(CMAKE_BUILD_TYPE release) include_directories(.) add_library( xbt SHARED sql/database.cpp sql/sql_query.cpp sql/sql_result.cpp ) install(DIRECTORY xbt DESTINATION include FILES_MATCHING PATTERN *.h PATTERN .svn EXCLUDE) install(TARGETS xbt DESTINATION lib) ___ 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] Coverage reporting to CDash with Bullseye 7.14.9
I have a CMake 2.8.2 based project that is using Bullseye Coverage and Visual Studio 10 along with CTest on Windows 7 64bit. This project is reporting building/testing/coverage results to a local CDash server. If I use Bullseye 7.14.0 the coverage results shown in CDash show decorated source with line by line indication of coverage when a given source file hyperlink is selected. If I use Bullseye 7.14.9, the coverage results are still reported but when I click on a link in CDash to see the source detail for a file, the resulting page has no source code. I know that those reports are generated at least in some part by the covbr tool that ships with Bullseye. Maybe Bullseye has changed something in their covbr output format or command line arguments (just speculating). Has anyone else seen this problem? It would be nice to be able to use the latest Bullseye version. -Derek ___ 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] Small, complete CPack example?
I'm looking all over for an end-to-end basic example of using CPack
to create a package with a single shared library target. It can
even be with the TGZ generator.
I already checked these pages:
http://www.cmake.org/cmake/help/cpack-2-8-docs.html#see:FrequentlyAskedQuestions
http://www.itk.org/Wiki/CMake:CPackConfiguration
http://www.cmake.org/pipermail/cmake/2008-September/024003.html
...and nothing helps. My CMake file just has a single shared
library target and when I run "make package", the built
library gets copied to the destination directory,
however the *.tgz file is empty but the generated
"install_manifest.txt" does have the path of the library in
the destination directory. The generated shell archive
is also empty, so is the generated *.pkg and *.dmg.
The question is, how to make the build artifacts go into
the package? A basic (even very basic) example would be
helpful.
Thanks,
Chris Wolf
P.S. Here is my current CMakeList.txt:
cmake_minimum_required(VERSION 2.8)
project(libusb)
set(NAME libusb)
include(CheckIncludeFiles)
include(CPack)
set(CPACK_PACKAGE_EXECUTABLES "libusb.dylib" "libusb-1.0.8")
#set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 1)
CHECK_INCLUDE_FILES (malloc.h HAVE_MALLOC_H)
if(APPLE)
set(CMAKE_OSX_ARCHITECTURES "ppc7400;ppc64;x86_64;i386")
set(TARGETSDK MacOSX10.5.sdk)
set(CMAKE_OSX_SYSROOT /Developer/SDKs/${TARGETSDK})
macro(ADD_FRAMEWORK fwname appname)
find_library(FRAMEWORK_${fwname}
NAMES ${fwname}
PATHS ${CMAKE_OSX_SYSROOT}/System/Library
PATH_SUFFIXES Frameworks
NO_DEFAULT_PATH)
if( ${FRAMEWORK_${fwname}} STREQUAL FRAMEWORK_${fwname}-NOTFOUND)
MESSAGE(ERROR ": Framework ${fwname} not found")
else()
TARGET_LINK_LIBRARIES(${appname} ${FRAMEWORK_${fwname}})
MESSAGE(STATUS "Framework ${fwname} found at ${FRAMEWORK_${fwname}}")
endif()
endmacro(ADD_FRAMEWORK)
endif(APPLE)
include_directories(.)
set(libusb_srcs descriptor.c libusb.h core.c io.c libusbi.h sync.c)
if(APPLE)
set(libusb_srcs ${libusb_srcs} os/darwin_usb.h os/darwin_usb.c)
endif(APPLE)
add_library(usb SHARED ${libusb_srcs})
install(TARGETS "usb" LIBRARY
DESTINATION /tmp/local/crap/lib
PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE
GROUP_READ GROUP_EXECUTE
WORLD_READ WORLD_EXECUTE)
if(APPLE)
add_framework(CoreFoundation usb)
add_framework(IOKit usb)
endif(APPLE)
___
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] Dependency bug in cmake with a custom-command
On Thu, Aug 5, 2010 at 2:29 PM, Andreas Pakulat wrote: > Hi, > > we're currently hitting what looks like a dependency problem with CMake > and a custom-command. Unfortunately I couldn't reproduce this so far > with a small example and it also only happens with one of the targets > we're building in kdevplatform. This code was recently added, but looks > the same as another plugin cmake-code and cpp-code wise. > > Ok, so here's the deal: We're using a KDE macro to run Qt's uic on our > .ui files and add the generated header filename into a cmake variable. > This cmake variable is then passed onto a add_library call (through > another macro). Now when running make in a freshly created builddir > using -j3 or so, the rule for generating the ui_xxx.h header is not > executed before trying to compile the file that uses the header... > > I'm using CMake 2.8.2 here currently (or rather current HEAD of the > release branch) > > This problem is only reproduceable after a make clean, once I hit the > error and do another make -j3 run, the dependencies are proper and hence > the generation is done. > > I've noticed that after the first failing run the depend.make and > depend.internal files suddenly exist/have content. So it seems that > cmake generates this info 'too late' and hence doesn't generate the > ui-header early enough. Whats a bit strange though is that apparently in > other plugins this stuff works. > > One more info: I'm seeing the 'Scanning dependencies of target > kdevpatchreview' message a lot later than the error when using -k with > make. And at that point I also see the 'Generating ui_xxx.h' message. > > Andreas > > -- > Good news from afar can bring you a welcome visitor. > ___ > 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 > So, you say it "looks the same" as other plugins that do not demonstrate the problem... but there must be some differences. What are the differences? Can you re-name things in yours to the same names as one that works, and then do a "diff" ...? Or just send a few code snippets along that look different? There are lots of folks doing Qt stuff with CMake, and I do not recall hearing of anything like this recently. I'd think it should work, so there must be some small difference in your CMakeLists.txt file (or something it includes) that is triggering this issue. Let us know more details... easier to help when looking at code or cmake output. Thanks, David ___ 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] Dependency bug in cmake with a custom-command
Do you need to set the sourcefile property GENERATED to true? (I'd think that would be automatic, but worth a try.) Ryan On Thu, Aug 5, 2010 at 1:29 PM, Andreas Pakulat wrote: > Hi, > > we're currently hitting what looks like a dependency problem with CMake > and a custom-command. Unfortunately I couldn't reproduce this so far > with a small example and it also only happens with one of the targets > we're building in kdevplatform. This code was recently added, but looks > the same as another plugin cmake-code and cpp-code wise. > > Ok, so here's the deal: We're using a KDE macro to run Qt's uic on our > .ui files and add the generated header filename into a cmake variable. > This cmake variable is then passed onto a add_library call (through > another macro). Now when running make in a freshly created builddir > using -j3 or so, the rule for generating the ui_xxx.h header is not > executed before trying to compile the file that uses the header... > > I'm using CMake 2.8.2 here currently (or rather current HEAD of the > release branch) > > This problem is only reproduceable after a make clean, once I hit the > error and do another make -j3 run, the dependencies are proper and hence > the generation is done. > > I've noticed that after the first failing run the depend.make and > depend.internal files suddenly exist/have content. So it seems that > cmake generates this info 'too late' and hence doesn't generate the > ui-header early enough. Whats a bit strange though is that apparently in > other plugins this stuff works. > > One more info: I'm seeing the 'Scanning dependencies of target > kdevpatchreview' message a lot later than the error when using -k with > make. And at that point I also see the 'Generating ui_xxx.h' message. > > Andreas > > -- > Good news from afar can bring you a welcome visitor. > ___ > 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 > -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com Internal VRAC/HCI Site: http://tinyurl.com/rpavlik ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cannot find "modules" directory on MacOS
Today is my first time messing with CMake, so I don't have any prior versions. Well, I was reading this page: http://www.cmake.org/Wiki/CMake:How_To_Write_Platform_Checks because I wanted to use: INCLUDE (CheckIncludeFiles) This page has the following paragraph: Additionally to the builtin commands, cmake offers more commands implemented by cmake script files, called modules. These files are located in the cmake module directory, on UNIX systems is this by default /usr/local/share/CMake/Modules . So before I even just tried the module, I went looking for it to see what the source looked like. When I didn't find it in /usr/share/cmake-2.8 or /usr/local/share/cmake-2.8, as suggested by the Wiki page and this thread: http://www.mail-archive.com/cmake@cmake.org/msg04790.html I just assumed something was wrong and that the installation was not complete. In fact, I jumped to a conclusion - apparently, when those extra resources are in the application bundle, then can be found, in-place, even with the command-line cmake executable. In other words, I was wrong - those files are fine to be under, "/Applications/CMake\ 2.8-2.app/Contents/" Thanks for quickly pointing that out. I have more development experience on UNIX/Linux, which is how I made this mistake. However, I would recommend updating that Wiki page to mention that on MacOS the modules are located within the application bundle, under "/Applications/CMake 2.8-2.app/Contents/share/cmake-2.8/Modules" Also, I think the man pages still need to be copied, or symlinked, or the MANPATH updated. Thanks, Chris Wolf On 8/5/10 3:18 PM, Ryan Pavlik wrote: > How are you running cmake? I've used the installer from the web site on my > mac, and it works fine both from the GUI and the command line, and I did not > have to move/link the modules. Is it possible that you have some other > version of cmake installed (from macports, fink, or brew?)? Try removing > it, if that is the case, and installing anew from the cmake-provided > binaries. > > Ryan > > On Thu, Aug 5, 2010 at 2:08 PM, Chris Wolf wrote: > >> I already searched around and found this answer: >> >> http://www.mail-archive.com/cmake@cmake.org/msg04790.html >> >> ...however, there is NO such directory, " /usr/share/cmake*" on my system. >> (nor "/usr/local/share/cmake*") >> >> I tried to investigate: >> >> $ cd /Library/Receipts/cmake-2.8.2-Darwin-universal.pkg/Contents >> $ lsbom -s Archive.bom | grep -i module >> ./CMake >> 2.8-2.app/Contents/share/cmake-2.8/Modules/AddFileDependencies.cmake >> ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake >> ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/CMake.cmake >> ./CMake >> 2.8-2.app/Contents/share/cmake-2.8/Modules/CMakeASM-ATTInformation.cmake >> ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/ >> CMakeASMCompiler.cmake.in >> ./CMake >> 2.8-2.app/Contents/share/cmake-2.8/Modules/CMakeASMInformation.cmake >> [...] >> >> So obviously, they're in the package and the installer was supposed to >> have put the modules on the system, either in >> /usr/share or /usr/local/share but they're not there. >> >> Then I tried looking in the Application bundle: >> >> $ cd /Applications/CMake 2.8-2.app/Contents >> $ ls -l >> drwxr-xr-x 8 cwolf cwolf 272 Aug 5 14:52 bin >> drwxr-xr-x 3 cwolf cwolf 102 Jun 28 11:12 doc >> drwxr-xr-x 3 cwolf cwolf 102 Jun 28 11:13 man >> drwxr-xr-x 6 cwolf cwolf 204 Jun 28 11:12 share >> [...] >> >> ...so that's where they are. When I ran the installer, I elected to >> let it create symlinks in /usr/local, but it only did that for the >> binaries in "bin". >> >> The "postflight" script should have also symlinked, or copied, >> the "doc", "man" and "share" directory hierarchies content also. >> >> I can do this manually myself, but I just wanted to point out the >> issue with the MacOS installer package for cmake-2.8.2. >> >> Thanks, >> >> Chris Wolf >> >> ___ >> 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] Building source RPMs?
On 05/08/10 20:25, Alexander Neundorf wrote: > On Thursday 05 August 2010, Magnus Therning wrote: >> On Thu, Aug 5, 2010 at 10:39, Eric Noulard >> wrote: > ... >>> What is your usage pattern? >> >> We ship most of our sources as source RPMs since most of our changes are >> added patches to upstream (CentOS) RPMs. >> >> It is just nice to also ship the source of our own code as RPMs rather >> than as tar-ball. However, I don't see a big problem with simply >> dropping use of CPack and writing the SPEC files manually. It would >> just be a nice-to-have is all. > > Somehow I don't really understand how a source RPM or source deb > generator would make sense for CPack. E.g. a source deb is the plain > source package, plus an optional patch, plus a file which describes how > to build it. IMO the patch would be always non-existent if generated > with CPack (since this generates the package directly from the original > source tree), so the only thing left would be to generate the spec file. > I guess for a source RPM it's similar ? You misunderstood me. Our stuff consists of two types of RPMs: 1. Source taken from upstream distro (CentOS), with patches added. We use the source RPM upstream provides, with minimal changes to SPEC files to get our patches into the resulting binary RPM. To comply with licenses we ship source RPMs that include our patches. 2. In-house developed code. The current build system builds binary RPMs, since that's what the installer is good at handling. It also simplifies distribution of updates. The build system also spits out source RPMs, since some things require releasing of source. This is what we're looking at building with CMake/CPack. Hence my question. Hopefully this makes it clearer. /M signature.asc Description: OpenPGP digital signature ___ 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] Building source RPMs?
On Thu, Aug 5, 2010 at 9:25 PM, Alexander Neundorf wrote: > Somehow I don't really understand how a source RPM or source deb generator > would make sense for CPack. > E.g. a source deb is the plain source package, plus an optional patch, plus a > file which describes how to build it. > IMO the patch would be always non-existent if generated with CPack (since this > generates the package directly from the original source tree), so the only > thing left would be to generate the spec file. > I guess for a source RPM it's similar ? It'd provide a place to list the build dependencies, for example. Olaf ___ 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] Building source RPMs?
On Thursday 05 August 2010, Magnus Therning wrote: > On Thu, Aug 5, 2010 at 10:39, Eric Noulard wrote: ... > > What is your usage pattern? > > We ship most of our sources as source RPMs since most of our changes are > added patches to upstream (CentOS) RPMs. > > It is just nice to also ship the source of our own code as RPMs rather than > as tar-ball. However, I don't see a big problem with simply dropping use > of CPack and writing the SPEC files manually. It would just be a > nice-to-have is all. Somehow I don't really understand how a source RPM or source deb generator would make sense for CPack. E.g. a source deb is the plain source package, plus an optional patch, plus a file which describes how to build it. IMO the patch would be always non-existent if generated with CPack (since this generates the package directly from the original source tree), so the only thing left would be to generate the spec file. I guess for a source RPM it's similar ? 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] Cannot find "modules" directory on MacOS
How are you running cmake? I've used the installer from the web site on my mac, and it works fine both from the GUI and the command line, and I did not have to move/link the modules. Is it possible that you have some other version of cmake installed (from macports, fink, or brew?)? Try removing it, if that is the case, and installing anew from the cmake-provided binaries. Ryan On Thu, Aug 5, 2010 at 2:08 PM, Chris Wolf wrote: > I already searched around and found this answer: > > http://www.mail-archive.com/cmake@cmake.org/msg04790.html > > ...however, there is NO such directory, " /usr/share/cmake*" on my system. > (nor "/usr/local/share/cmake*") > > I tried to investigate: > > $ cd /Library/Receipts/cmake-2.8.2-Darwin-universal.pkg/Contents > $ lsbom -s Archive.bom | grep -i module > ./CMake > 2.8-2.app/Contents/share/cmake-2.8/Modules/AddFileDependencies.cmake > ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake > ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/CMake.cmake > ./CMake > 2.8-2.app/Contents/share/cmake-2.8/Modules/CMakeASM-ATTInformation.cmake > ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/ > CMakeASMCompiler.cmake.in > ./CMake > 2.8-2.app/Contents/share/cmake-2.8/Modules/CMakeASMInformation.cmake > [...] > > So obviously, they're in the package and the installer was supposed to > have put the modules on the system, either in > /usr/share or /usr/local/share but they're not there. > > Then I tried looking in the Application bundle: > > $ cd /Applications/CMake 2.8-2.app/Contents > $ ls -l > drwxr-xr-x 8 cwolf cwolf 272 Aug 5 14:52 bin > drwxr-xr-x 3 cwolf cwolf 102 Jun 28 11:12 doc > drwxr-xr-x 3 cwolf cwolf 102 Jun 28 11:13 man > drwxr-xr-x 6 cwolf cwolf 204 Jun 28 11:12 share > [...] > > ...so that's where they are. When I ran the installer, I elected to > let it create symlinks in /usr/local, but it only did that for the > binaries in "bin". > > The "postflight" script should have also symlinked, or copied, > the "doc", "man" and "share" directory hierarchies content also. > > I can do this manually myself, but I just wanted to point out the > issue with the MacOS installer package for cmake-2.8.2. > > Thanks, > > Chris Wolf > > ___ > 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 > -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com Internal VRAC/HCI Site: http://tinyurl.com/rpavlik ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cannot find "modules" directory on MacOS
I already searched around and found this answer: http://www.mail-archive.com/cmake@cmake.org/msg04790.html ...however, there is NO such directory, " /usr/share/cmake*" on my system. (nor "/usr/local/share/cmake*") I tried to investigate: $ cd /Library/Receipts/cmake-2.8.2-Darwin-universal.pkg/Contents $ lsbom -s Archive.bom | grep -i module ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/AddFileDependencies.cmake ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/CMake.cmake ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/CMakeASM-ATTInformation.cmake ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/CMakeASMCompiler.cmake.in ./CMake 2.8-2.app/Contents/share/cmake-2.8/Modules/CMakeASMInformation.cmake [...] So obviously, they're in the package and the installer was supposed to have put the modules on the system, either in /usr/share or /usr/local/share but they're not there. Then I tried looking in the Application bundle: $ cd /Applications/CMake 2.8-2.app/Contents $ ls -l drwxr-xr-x 8 cwolf cwolf 272 Aug 5 14:52 bin drwxr-xr-x 3 cwolf cwolf 102 Jun 28 11:12 doc drwxr-xr-x 3 cwolf cwolf 102 Jun 28 11:13 man drwxr-xr-x 6 cwolf cwolf 204 Jun 28 11:12 share [...] ...so that's where they are. When I ran the installer, I elected to let it create symlinks in /usr/local, but it only did that for the binaries in "bin". The "postflight" script should have also symlinked, or copied, the "doc", "man" and "share" directory hierarchies content also. I can do this manually myself, but I just wanted to point out the issue with the MacOS installer package for cmake-2.8.2. Thanks, Chris Wolf ___ 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] Dependency bug in cmake with a custom-command
Hi, we're currently hitting what looks like a dependency problem with CMake and a custom-command. Unfortunately I couldn't reproduce this so far with a small example and it also only happens with one of the targets we're building in kdevplatform. This code was recently added, but looks the same as another plugin cmake-code and cpp-code wise. Ok, so here's the deal: We're using a KDE macro to run Qt's uic on our .ui files and add the generated header filename into a cmake variable. This cmake variable is then passed onto a add_library call (through another macro). Now when running make in a freshly created builddir using -j3 or so, the rule for generating the ui_xxx.h header is not executed before trying to compile the file that uses the header... I'm using CMake 2.8.2 here currently (or rather current HEAD of the release branch) This problem is only reproduceable after a make clean, once I hit the error and do another make -j3 run, the dependencies are proper and hence the generation is done. I've noticed that after the first failing run the depend.make and depend.internal files suddenly exist/have content. So it seems that cmake generates this info 'too late' and hence doesn't generate the ui-header early enough. Whats a bit strange though is that apparently in other plugins this stuff works. One more info: I'm seeing the 'Scanning dependencies of target kdevpatchreview' message a lot later than the error when using -k with make. And at that point I also see the 'Generating ui_xxx.h' message. Andreas -- Good news from afar can bring you a welcome visitor. ___ 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] N projects/packages that depend
Hi, I have in my repository N projects/packages, that depend on each other. E.g. project 1 found with find_package( wxDocview ), needs to build first, before i can do project2. I can not generate all at once all cmake binary project files, since the project2, call find_package on project 1. Still i like to have an overall CmakeLists.txt file. So i started in that top file with find_package( wxDocview), right after cmake generated the binary stuff for that wxDocview project, on which the second project depends. If the compiled project is not found i tell the user to first make it. But when i type make in project 1, it first runs cmake again, and tells me the again that i should first make it. An that is no good. Well i don't see how to do i :-(. Does someone know how to handle such a situation? Thanks, Klaas ___ 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] Help with dependency on custom command output
On 08/05/2010 10:42 AM, David Cole wrote: Shouldn't that be this? add_custom_command(OUTPUT test_diagnostics_get_mean.icc COMMAND python test_diagnostics_crosscheck.py DEPENDS test_diagnostics_crosscheck.py) add_executable(test_diagnostics test_diagnostics.cc test_diagnostics_get_mean.icc) Yes, that does it. Thanks. FYI, add_dependencies is only used to establish target-to-target dependencies (ordering), not file level dependencies... http://cmake.org/cmake/help/cmake-2-8-docs.html#command:add_dependencies I think that was, in fact, the source of my confusion. Thanks again, Jim Amundson ___ 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] Help with dependency on custom command output
Shouldn't that be this? add_custom_command(OUTPUT test_diagnostics_get_mean.icc COMMAND python test_diagnostics_crosscheck.py DEPENDS test_diagnostics_crosscheck.py) add_executable(test_diagnostics test_diagnostics.cc test_diagnostics_get_mean.icc) FYI, add_dependencies is only used to establish target-to-target dependencies (ordering), not file level dependencies... http://cmake.org/cmake/help/cmake-2-8-docs.html#command:add_dependencies HTH, David On Thu, Aug 5, 2010 at 11:30 AM, James Amundson wrote: > I cannot get the following simple build process to work. I must be missing > something. > > I build a (test) executable test_diagnostics, which depends on a source > file test_diagnostics.cc and a generated file test_diagnostics_get_mean.icc. > I generate the latter with >python test_diagnostics_crosscheck.py > > I thought the following would work: > > add_custom_command(OUTPUT test_diagnostics_get_mean.icc >COMMAND python test_diagnostics_crosscheck.py >DEPENDS test_diagnostics_crosscheck.py) > add_executable(test_diagnostics test_diagnostics.cc) > add_dependencies(test_diagnostics test_diagnostics_get_mean.icc) > > However > > make test_diagnostics > > fails because test_diagnostics_get_mean.icc is not found. I have to invoke > > make test_diagnostics_get_mean.icc > > manually in order to get it to work. What am I missing? > > Thanks, > Jim Amundson > ___ > 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] Help with dependency on custom command output
I cannot get the following simple build process to work. I must be missing something. I build a (test) executable test_diagnostics, which depends on a source file test_diagnostics.cc and a generated file test_diagnostics_get_mean.icc. I generate the latter with python test_diagnostics_crosscheck.py I thought the following would work: add_custom_command(OUTPUT test_diagnostics_get_mean.icc COMMAND python test_diagnostics_crosscheck.py DEPENDS test_diagnostics_crosscheck.py) add_executable(test_diagnostics test_diagnostics.cc) add_dependencies(test_diagnostics test_diagnostics_get_mean.icc) However make test_diagnostics fails because test_diagnostics_get_mean.icc is not found. I have to invoke make test_diagnostics_get_mean.icc manually in order to get it to work. What am I missing? Thanks, Jim Amundson ___ 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] Building source RPMs?
On Thu, Aug 5, 2010 at 10:39, Eric Noulard wrote: > 2010/8/5 Magnus Therning : >> I'm currently using CPack to build binary RPMs, is there a way to also >> generate a source RPM? > > Not yet...with CPackRPM. > > Building a source RPM with CMake/CPack is not as easy as building a > binary RPM. Because currently the spec file used to build a binary RPM > is a "short-cutted" one: > - the %prep step is a simple move of directory > - the %build is void (because CMake BUILDTOOL should have already done > the build > - the %install is a simple move too (because CPack did the install > on it's own) > > This is due to the fact that when you call CPack, > - CMake has been called > - The software has been built > - CPack will call install for you BEFORE calling the CPackRPM generator > in the end CPackRPM "just" have to package the "already built and > installed file". > > In a source RPM you should specify the steps (%prep, %build, %install) > what CMake/CPack usually do. So basically the RPM spec file to use > for building a source RPM won't be the same as the one used to build > the current binary RPM. > > So implementing a "Source RPM" generator is doable, > and in fact it was done in the UseRPMTools.cmake macro > http://www.cmake.org/Wiki/CMakeUserUseRPMTools > which is the ancestor of CPackRPM. > > The drawback of the old UseRPMTools is that even for a binary RPM > it will redo all the steps including calling CMake etc... > > Why do you need to build a Source RPM with CPack ? To match the behaviour of the current build system :-) I think that using the VCS archive feature will be as good a replacement though. > What is your usage pattern? We ship most of our sources as source RPMs since most of our changes are added patches to upstream (CentOS) RPMs. It is just nice to also ship the source of our own code as RPMs rather than as tar-ball. However, I don't see a big problem with simply dropping use of CPack and writing the SPEC files manually. It would just be a nice-to-have is all. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ 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] include_directories and qt4_wrap_cpp
On 08/05/2010 03:28 AM, Dennis Schridde wrote: On Monday 02 August 2010 17:20:36 Dennis Schridde wrote: Replacing ".framework" with "\\.framework" works. Was this change already commited? I.e. is the problem solved in the sources now? Yes, it is in git, but its still waiting for a review for merging into master. Clint ___ 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] How to obtain "date of the day"
On Thu, Aug 5, 2010 at 9:46 AM, Jean-Christophe Fillion-Robin <
jchris.filli...@kitware.com> wrote:
> hi Folks,
>
> Earlier in the day, somebody asked me how he could obtain "today date"
> using cmake.
> I replied there was no direct way to obtain the date and I told him to use
> a macro I wrote.
> See
> http://viewvc.slicer.org/viewcvs.cgi/trunk/CMake/Slicer3TodayMacro.cmake?rev=11898&view=log
>
> Is there a better a way to retrieve "today date" ?
>
Not yet. But it would be a relatively easy feature to add to CMake if
somebody wants to sponsor it.
I envision a new cmake command, or an extension to an existing command (like
string with a NOW or NOW_UTC arg...) that returns a complete timestamp
string (something like "2010-08-04 14:00:44.235675 UTC") and/or the
components of such a string as a cmake list ("2010;8;4;14;0;44;235675;UTC").
Any sponsors out there? :-)
David
> Thks
> Jc
>
> --
> Phone: 1-518-836-2174
> Ext: 304
>
> ___
> 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] How to obtain "date of the day"
On 5. Aug, 2010, at 15:46 , Jean-Christophe Fillion-Robin wrote: > hi Folks, > > Earlier in the day, somebody asked me how he could obtain "today date" using > cmake. > I replied there was no direct way to obtain the date and I told him to use a > macro I wrote. > See > http://viewvc.slicer.org/viewcvs.cgi/trunk/CMake/Slicer3TodayMacro.cmake?rev=11898&view=log > > Is there a better a way to retrieve "today date" ? > > Thks > Jc Not that I know of, it's come up occasionally on this list... The problem with this kind of macro is (IMHO) that it gives you the configure-date, not the build-date. For the latter you would need to call this macro as a CMake-script at build time. Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to obtain "date of the day"
hi Folks, Earlier in the day, somebody asked me how he could obtain "today date" using cmake. I replied there was no direct way to obtain the date and I told him to use a macro I wrote. See http://viewvc.slicer.org/viewcvs.cgi/trunk/CMake/Slicer3TodayMacro.cmake?rev=11898&view=log Is there a better a way to retrieve "today date" ? Thks Jc -- Phone: 1-518-836-2174 Ext: 304 ___ 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] include_directories and qt4_wrap_cpp
Ah yes, I always keep forgetting that you have to get the \ past the CMake parser... :-( Sorry for the noise. Michael On 5. Aug, 2010, at 12:07 , David Cole wrote: > No, he's right. "\\." when used in a CMake string(REGEX operation matches a > single dot exactly. The "\\" is required to get a single "\" into the > regular expression engine. > > > On Thu, Aug 5, 2010 at 5:39 AM, Michael Wild wrote: > >> >> On 5. Aug, 2010, at 11:28 , Dennis Schridde wrote: >> >>> On Monday 02 August 2010 17:20:36 Dennis Schridde wrote: Replacing >>> ".framework" with "\\.framework" works. >>> Was this change already >>> commited? >>> I.e. is the problem solved in the sources now? >>> >>> --Dennis >> >> IMHO this is wrong. \\. searches for a literal backslash. Although it works >> on your machine, it will break on Mac OS X where Qt is installed as a >> framework. >> >> Michael >> >> ___ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/listinfo/cmake >> ___ 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] include_directories and qt4_wrap_cpp
On Thursday 05 August 2010 11:39:00 Michael Wild wrote: > On 5. Aug, 2010, at 11:28 , Dennis Schridde wrote: > > On Monday 02 August 2010 17:20:36 Dennis Schridde wrote: > >> Replacing > > > > ".framework" with "\\.framework" works. > > Was this change already > > commited? > > I.e. is the problem solved in the sources now? > > > > --Dennis > > IMHO this is wrong. \\. searches for a literal backslash. Although it works > on your machine, it will break on Mac OS X where Qt is installed as a > framework. But \. did not work. So I assume that searching for the literal string "\." would require one to write "\." in the regexp (\\\ for the backslash, \\. for the dot)? --Dennis signature.asc Description: This is a digitally signed message part. ___ 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] include_directories and qt4_wrap_cpp
No, he's right. "\\." when used in a CMake string(REGEX operation matches a single dot exactly. The "\\" is required to get a single "\" into the regular expression engine. On Thu, Aug 5, 2010 at 5:39 AM, Michael Wild wrote: > > On 5. Aug, 2010, at 11:28 , Dennis Schridde wrote: > > > On Monday 02 August 2010 17:20:36 Dennis Schridde wrote: > >> Replacing > > ".framework" with "\\.framework" works. > > Was this change already > > commited? > > I.e. is the problem solved in the sources now? > > > > --Dennis > > IMHO this is wrong. \\. searches for a literal backslash. Although it works > on your machine, it will break on Mac OS X where Qt is installed as a > framework. > > Michael > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ 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] Building source RPMs?
2010/8/5 Magnus Therning : > I'm currently using CPack to build binary RPMs, is there a way to also > generate a source RPM? Not yet...with CPackRPM. Building a source RPM with CMake/CPack is not as easy as building a binary RPM. Because currently the spec file used to build a binary RPM is a "short-cutted" one: - the %prep step is a simple move of directory - the %build is void (because CMake BUILDTOOL should have already done the build - the %install is a simple move too (because CPack did the install on it's own) This is due to the fact that when you call CPack, - CMake has been called - The software has been built - CPack will call install for you BEFORE calling the CPackRPM generator in the end CPackRPM "just" have to package the "already built and installed file". In a source RPM you should specify the steps (%prep, %build, %install) what CMake/CPack usually do. So basically the RPM spec file to use for building a source RPM won't be the same as the one used to build the current binary RPM. So implementing a "Source RPM" generator is doable, and in fact it was done in the UseRPMTools.cmake macro http://www.cmake.org/Wiki/CMakeUserUseRPMTools which is the ancestor of CPackRPM. The drawback of the old UseRPMTools is that even for a binary RPM it will redo all the steps including calling CMake etc... Why do you need to build a Source RPM with CPack ? What is your usage pattern? -- 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] include_directories and qt4_wrap_cpp
On 5. Aug, 2010, at 11:28 , Dennis Schridde wrote: > On Monday 02 August 2010 17:20:36 Dennis Schridde wrote: >> Replacing > ".framework" with "\\.framework" works. > Was this change already > commited? > I.e. is the problem solved in the sources now? > > --Dennis IMHO this is wrong. \\. searches for a literal backslash. Although it works on your machine, it will break on Mac OS X where Qt is installed as a framework. Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] include_directories and qt4_wrap_cpp
On Monday 02 August 2010 17:20:36 Dennis Schridde wrote: > Replacing ".framework" with "\\.framework" works. Was this change already commited? I.e. is the problem solved in the sources now? --Dennis signature.asc Description: This is a digitally signed message part. ___ 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] Building source RPMs?
I'm currently using CPack to build binary RPMs, is there a way to also generate a source RPM? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ 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
