Re: [CMake] Problems with CPack/NSIS and CPACK_NSIS_MUI_FINISHPAGE_RUN
Hi,
sorry, I forgot to add the CMake/CPack Version.
I use cmake v2.8.6
Best Regards
Von: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] Im Auftrag von
NoRulez
Gesendet: Donnerstag, 17. November 2011 10:46
An: CMake MailingList
Betreff: [CMake] Problems with CPack/NSIS and CPACK_NSIS_MUI_FINISHPAGE_RUN
Hi,
the issue (http://public.kitware.com/Bug/view.php?id=11144) is already closed
but the problem still exists.
If I use the following:
SET(CPACK_NSIS_MUI_FINISHPAGE_RUN "${PROJECT_NAME}.exe")
Then the file project.nsi contains the following string and the application
isn’t launched:
!define MUI_FINISHPAGE_RUN "$INSTDIR\bin\MyProject"
If I use the following string instead to temporary fix the issue:
SET(CPACK_NSIS_MUI_FINISHPAGE_RUN "..${PROJECT_NAME}.exe")
Then the file contains:
!define MUI_FINISHPAGE_RUN "$INSTDIR\bin\..\MyProject"
With this the Application is launched successfully.
Any hints to avoid the “dirty” hack?
Best Regards
NoRulez
--
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] Install command incorrectly installing archive libraries
On 11/17/2011 06:12 PM, Stephen Torri wrote: > CMake Version: 2.8 > > Generator: Visual Studio 2008 > > Problem: Two install commands are used per library. First command > should only install libraries to lib/debug when the build type is > Debug. The second command should only install libraries to the > lib/release directory. When the build type is Debug than three > libraries .lib files are being installed to the lib\release directory. > > For example I have the following entries for a library: > > INSTALL ( TARGETS first > ARCHIVE DESTINATION lib/debug > LIBRARY DESTINATION lib/debug > RUNTIME DESTINATION lib/debug > CONFIGURATIONS Debug ) > > INSTALL ( TARGETS first > ARCHIVE DESTINATION lib/release > LIBRARY DESTINATION lib/release > RUNTIME DESTINATION lib/release > CONFIGURATIONS Release ) > > So when I run cpack -C Debug and use the installer I find first.lib in > both lib/debug and lib/release. I am not sure why this is the case. > Any ideas? > > Stephen I think you mis-read the install() documentation. Granted, it is a bit confusing and matching up the brackets is a bit tedious, but the CONFIGURATIONS option applies only to the preceeding DESTINATION option. So you could write everything in one single command: install(TARGETS first ARCHIVE DESTINATION lib/debug CONFIGURATIONS Debug LIBRARY DESTINATION lib/debug CONFIGURATIONS Debug RUNTIME DESTINATION lib/debug CONFIGURATIONS Debug ARCHIVE DESTINATION lib/release CONFIGURATIONS Release LIBRARY DESTINATION lib/release CONFIGURATIONS Release RUNTIME DESTINATION lib/release CONFIGURATIONS Release) HTH 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] [RFC] How to use pkg-config under Windows (... and OSX)?
On 2011-11-17 21:43+0100 Hendrik Sattler wrote: Am Donnerstag, 17. November 2011, 21:38:20 schrieb Hendrik Sattler: Am Donnerstag, 17. November 2011, 18:26:08 schrieb Alexander Neundorf: Let's say package Foo (unrelated to KDE, and unrelated to cmake) has been ported from UNIX to Windows, and installs a pkgconfig file. This pkgconfig file is generated at the time when the binary package for Foo is generated. Now a user downloads and installs the binary package of Foo, along with the included pkgconfig file, which contains the install path from build time. But the user can now decide where he will install this binary package. This may differ from what is recorded in the pkgconfig file in the binary package of Foo. So the Foo.pc file is installed, and contains e.g. "C:/Foo/include", but the user decides to install it to "D:/MyStuff/", so the include dir would be "D:/MyStuff/include". Now cmake comes into play. Let's say there is a project Bar, which uses Foo, so it does find_package(Foo). Now FindFoo.cmake uses pkgconfig: find_package(PkgConfig) pkg_check_modules(Foo ...) Now this will report C:/Foo/include (because this is what the pkgconfig-file contains), instead of D:/MyStuff/include, where the user decided to install it. No. Pkg-config should derive the prefix variable from the location of the .pc file. According to documentation, it does this on Windows, so it should report D:/MyStuff/include See http://cgit.freedesktop.org/pkg-config/tree/parse.c#n1136 Thanks, Hendrik for reminding me of that pkg-config feature. I haven't looked at that URL in any detail, but your summary jibes with the man page for pkg-config which states the following: WINDOWS SPECIALITIES If a .pc file is found in a directory that matches the usual conven‐ tions (i.e., ends with \lib\pkgconfig or \share\pkgconfig), the prefix for that package is assumed to be the grandparent of the directory where the file was found, and the prefix variable is overridden for that file accordingly. If the value of a variable in a .pc file begins with the original, non- overridden, value of the prefix variable, then the overridden value of prefix is used instead. So the explanation of why pkg-config works fine for the GTK+ stack of libraries is much simpler than I thought. The GTK+ *.pc files _are_ installed in a relative location within the install tree that matches the standard conventions. So the ~10 different prefix variables for the ~30 *.pc files are completely overridden in that case to correspond exactly to the up-to-date special install location chosen by the user at binary installation time. So everything works properly for pkg-config for the Windows case so long as the binary package in question installs the *.pc files in the right _relative_ location in the install tree. That standard is really easy for any software binary distribution to follow. So if any windows binary package is broken this way (remember nobody has given specifics of even one such broken package yet), it should be incredibly easy to fix. It concerns me that some posts in this thread took the assertion that pkg-config is systematically broken for Windows as the Gospel truth without investigating that assertion any further. That assertion has now been proved to be a myth by my prior investigation showing pkg-config works fine to find compile and link information for 33 GTK+ libraries installed in a non-standard location for a Windows platform (Wine). Furthermore, the man page section for pkg-config explains the simple reason why that works which even more strongly answers the assertion. Alex, is it possible your KDE Windows developers who are objecting to pkg-config tried a version from years ago when it did not have all these Windows issues sorted out? I suggest you tell them to investigate again using modern pkg-config. For example, they could follow the experiment I tried using the all-in-one GTK+ 2.22.1 bundle you can download from http://www.gtk.org/download/win32.php. If that works (which it should do if the bundle is properly installed) or if they use a modern binary version of pkg-config for Windows from that same location, ask them to attempt to find any Windows binary package that is broken with regard to pkg-config. There might be some of those. But I very much doubt that is a systematic problem since it is so straightforward (install the *.pc files in the correct relative location in the install tree) to deal with the pkg-config Windows issue the KDE Windows developers have been so concerned about. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting sof
[CMake] (no subject)
http://11thrru.org/admin/poefdg.htm -- 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] [RFC] How to use pkg-config under Windows (... and OSX)?
Hi Alex:
On 2011-11-17 18:26+0100 Alexander Neundorf wrote:
The [pkg-config Windows] issue is the following:
Let's say package Foo (unrelated to KDE, and unrelated to cmake) has been
ported from UNIX to Windows, and installs a pkgconfig file.
This pkgconfig file is generated at the time when the binary package for Foo
is generated.
Now a user downloads and installs the binary package of Foo, along with the
included pkgconfig file, which contains the install path from build time.
But the user can now decide where he will install this binary package.
This may differ from what is recorded in the pkgconfig file in the binary
package of Foo.
So the Foo.pc file is installed, and contains e.g. "C:/Foo/include", but the
user decides to install it to "D:/MyStuff/", so the include dir would be
"D:/MyStuff/include".
That is an interesting example because that is exactly what I did with GTK+
for Windows on my Wine platform. That is, I installed that beast in
its own special directory rather than in a standard Wine location. So
let's try to investigate that case.
Here are some specific (line wrapped for mailing) pkg-config results I
get for a component of GTK+ under Wine using the MSYS version of bash
(a nice familiar working environment on Windows for someone like me
that is not that familiar with the platform).
bash.exe-3.1$ which pkg-config
/z/home/wine/gtkplus-2.22.1/bin/pkg-config.exe
bash.exe-3.1$ pkg-config --cflags pangocairo
-mms-bitfields
-IZ:/home/wine/gtkplus-2.22.1/include/pango-1.0
-IZ:/home/wine/gtkplus-2.22.1/include/cairo
-IZ:/home/wine/gtkplus-2.22.1/include/glib-2.0
-IZ:/home/wine/gtkplus-2.22.1/lib/glib-2.0/include
-IZ:/home/wine/gtkplus-2.22.1/include
-IZ:/home/wine/gtkplus-2.22.1/include/freetype2
-IZ:/home/wine/gtkplus-2.22.1/include/libpng14
bash.exe-3.1$ ls Z:/home/wine/gtkplus-2.22.1/include/freetype2
freetype
That last "ls" command shows the header files are located in the
special install location I used for the GTK+ stack of libraries (with
prefix Z:/home/wine/gtkplus-2.22.1) for Windows. So this is a nice
example of working *.pc files on Windows that were installed in a
non-standard location.
Let's look at the pangocairo.pc file to see how this apparently works.
That file contains the following:
prefix=c:/devel/target/18e9007417f775a5bc83c60917e98632
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: Pango Cairo
Description: Cairo rendering support for Pango
Version: 1.28.3
Requires: pango cairo
Libs: -L${libdir} -lpangocairo-1.0
Cflags: -I${includedir}/pango-1.0
That weird numerical file name for the prefix location appears to be
the key. There are 33 *.pc files distributed with GTK+, but only 10
unique numerical prefixes. So I assume those 10 prefixes correspond
to each independent software package within the GTK+ stack of
packages, and apparently some arrangement is made to update those 10
special file locations whenever (as in my case) the user specifies a
non-standard install location for the GTK+ stack.
So with care (as has apparently happened for the Windows binary
installer for the GTK+ stack of libraries) the Windows version of
pkg-config works fine for arbitrary binary package installation
locations chosen by the user.
I would claim that the GTK+ stack of libraries (which covers 33
different libraries from the above numbers) is the primary source of
pkg-config *.pc files for the Windows case. So the above good results
(assuming they are not just confined to the pangocairo subset of the
GTK+ stack that I have tested above) cover a huge amount of territory.
The only other pkg-config cases I am familiar with on the Windows
platform is libLASi (a library that produces nice PostScript results
for TrueType fonts) and PLplot itself. However, in those cases only
source distributions are available so installation prefixes for the
*.pc files are automatically taken care of in the install part of
those builds. However, if we ever make a binary distribution of
libLASi or PLplot for Windows we will have to pay attention to this
issue.
There are several possibilities I can think of to explain the
difficulties the KDE developers have encountered with pkg-config
for binary packages on Windows.
I. There may be parts of KDE that configure *.pc pkg-config files now,
but where the Windows binary installer for that KDE component does not
properly update the prefix location pointed to by those *.pc files.
It should be straightforward for KDE developers to fix such Windows
binary installer bugs following the trail pioneered by GTK+.
II. There may be parts of KDE that have a dependency on some external
non-GTK+ binary package that configures *.pc files but which has a
broken binary installer that does not update the prefix location
pointed to by those files. That, of course, would be a bug that was
external to KDE, but at least the KDE developers could report it and
hope that those external packages eventually fix such installer bugs
Re: [CMake] [RFC] How to use pkg-config under Windows (... and OSX)?
Am Donnerstag, 17. November 2011, 21:38:20 schrieb Hendrik Sattler: > Am Donnerstag, 17. November 2011, 18:26:08 schrieb Alexander Neundorf: > > Let's say package Foo (unrelated to KDE, and unrelated to cmake) has been > > ported from UNIX to Windows, and installs a pkgconfig file. > > This pkgconfig file is generated at the time when the binary package for > > Foo is generated. > > > > Now a user downloads and installs the binary package of Foo, along with > > the included pkgconfig file, which contains the install path from build > > time. But the user can now decide where he will install this binary > > package. This may differ from what is recorded in the pkgconfig file in > > the binary package of Foo. > > So the Foo.pc file is installed, and contains e.g. "C:/Foo/include", but > > the user decides to install it to "D:/MyStuff/", so the include dir would > > be "D:/MyStuff/include". > > > > > > Now cmake comes into play. > > Let's say there is a project Bar, which uses Foo, so it does > > find_package(Foo). > > > > Now FindFoo.cmake uses pkgconfig: > > > > find_package(PkgConfig) > > pkg_check_modules(Foo ...) > > > > Now this will report C:/Foo/include (because this is what the > > pkgconfig-file contains), instead of D:/MyStuff/include, where the user > > decided to install it. > > No. Pkg-config should derive the prefix variable from the location of the > .pc file. According to documentation, it does this on Windows, so it > should report D:/MyStuff/include See http://cgit.freedesktop.org/pkg-config/tree/parse.c#n1136 HS -- 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] [RFC] How to use pkg-config under Windows (... and OSX)?
Am Donnerstag, 17. November 2011, 18:26:08 schrieb Alexander Neundorf: > Let's say package Foo (unrelated to KDE, and unrelated to cmake) has been > ported from UNIX to Windows, and installs a pkgconfig file. > This pkgconfig file is generated at the time when the binary package for > Foo is generated. > > Now a user downloads and installs the binary package of Foo, along with the > included pkgconfig file, which contains the install path from build time. > But the user can now decide where he will install this binary package. > This may differ from what is recorded in the pkgconfig file in the binary > package of Foo. > So the Foo.pc file is installed, and contains e.g. "C:/Foo/include", but > the user decides to install it to "D:/MyStuff/", so the include dir would > be "D:/MyStuff/include". > > > Now cmake comes into play. > Let's say there is a project Bar, which uses Foo, so it does > find_package(Foo). > > Now FindFoo.cmake uses pkgconfig: > > find_package(PkgConfig) > pkg_check_modules(Foo ...) > > Now this will report C:/Foo/include (because this is what the > pkgconfig-file contains), instead of D:/MyStuff/include, where the user > decided to install it. No. Pkg-config should derive the prefix variable from the location of the .pc file. According to documentation, it does this on Windows, so it should report D:/MyStuff/include HS -- 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] [RFC] How to use pkg-config under Windows (... and OSX)?
Am Donnerstag, 17. November 2011, 14:36:00 schrieb David Cole:
> On Thu, Nov 17, 2011 at 2:06 PM, Alexander Neundorf
>
> wrote:
> > On Thursday 17 November 2011, David Cole wrote:
> > ...
> >
> >> If a project does something like this (distributes a file with
> >> build/install time information in it) but then lets the end user of
> >> the binary installation put it wherever they please.. then the
> I think we should completely ignore pkg-config on the grounds that
> their packages are not re-locatable, yet there are some packages that
> allow relocation anyhow. It should simply be made clear to everyone
> that pkg-config packages must not be, cannot be relocated.
> But. if you insist on supporting pkg-config to appease those who
> would use it anyway despite this limitation, then I would vote for
> something like this:
>
> if(NOT DEFINED CMAKE_USE_PKGCONFIG)
> # Default to using it:
> set(CMAKE_USE_PKGCONFIG 1)
> # But not on Mac or Windows, where end-user relocation is common practice:
> if(APPLE OR WIN32)
> set(CMAKE_USE_PKGCONFIG 0)
> endif()
> endif()
>
> if(CMAKE_USE_PKGCONFIG)
> pkgconfig stuff...
> endif()
Or something different: in case we suspect a broken platform, or
CMAKE_PKGCONFIG_OVERRIDE_${PACKAGE} is set, try to replace the prefix returned
by pkgconfig with the prefix of the .pc file.
Or simply ignore the results pkgconfig returns if those files do not exist.
Eike
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] (no subject)
http://label.heavyartillery.us/packages/email_list_signup/single_pages/dashboard/reports/fkgfhdol.htm -- 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] [RFC] How to use pkg-config under Windows (... and OSX)?
On Thu, Nov 17, 2011 at 2:06 PM, Alexander Neundorf wrote: > On Thursday 17 November 2011, David Cole wrote: > ... >> If a project does something like this (distributes a file with >> build/install time information in it) but then lets the end user of >> the binary installation put it wherever they please.. then the > > that's what I hear from our Windows developers. > >> distributed files should not contain any build/install time >> information in them, > > But according to what I hard this is what is done... > >> but rather should parse and use their actual end >> user install location if they need to provide that information on an >> end user's system. > > ...instead of this. > I also don't know whether pkgconfig supports something like $ORIGIN to > reference its own location in pc-files, which might help. > >> It sounds to me like pkg-config is simply not suitable for use with >> packages that may be installed/copied anywhere. > > Same here. > >> What is the problem we are trying to solve? > > From my very private POV: > I'm reviewing the Find-modules we have in KDE. > Many of them do > > if(NOT WIN32) > pkgconfig stuff... > endif() > > Now, I do not know from personal experience whether this if() make sense or > not. > > If it does make sense, then it might make sense for any package. In that case, > it would also make sense to have a global solution for this (like an option > CMAKE_SKIP_PKGCONFIG_ON_WIN32), instead of having to put this if() in each and > every Find-module. > > If the if() doesn't make sense, then it can be simply removed, and pkgconfig > is used everywhere. But our Windows developers said they don't want that. > > OTOH, since the Find-module must also work without pkgconfig (since we cannot > rely on that it exists everywhere), one could also argue that pkgconfig is > unnecessary completely in Find-modules, but then another group of people > starts complaining that we are ignoring existing standards and they really > want to use pkgconfig. > > So, what I'd like to get, is first some more opinions and experiences with > this, and as result some reasonable guidelines how to use pkgconfig properly > (or not). > > Alex > I think we should completely ignore pkg-config on the grounds that their packages are not re-locatable, yet there are some packages that allow relocation anyhow. It should simply be made clear to everyone that pkg-config packages must not be, cannot be relocated. Or, if we are wrong in this conclusion, somebody who cares about pkg-config as an "existing standard" should step forward and defend the inexplicable practice of relocating non-relocatable packages and then informing queriers of the old location... But. if you insist on supporting pkg-config to appease those who would use it anyway despite this limitation, then I would vote for something like this: if(NOT DEFINED CMAKE_USE_PKGCONFIG) # Default to using it: set(CMAKE_USE_PKGCONFIG 1) # But not on Mac or Windows, where end-user relocation is common practice: if(APPLE OR WIN32) set(CMAKE_USE_PKGCONFIG 0) endif() endif() if(CMAKE_USE_PKGCONFIG) pkgconfig stuff... endif() up to 4 cents now, 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] [RFC] How to use pkg-config under Windows (... and OSX)?
On Thursday 17 November 2011, David Cole wrote: ... > If a project does something like this (distributes a file with > build/install time information in it) but then lets the end user of > the binary installation put it wherever they please.. then the that's what I hear from our Windows developers. > distributed files should not contain any build/install time > information in them, But according to what I hard this is what is done... > but rather should parse and use their actual end > user install location if they need to provide that information on an > end user's system. ...instead of this. I also don't know whether pkgconfig supports something like $ORIGIN to reference its own location in pc-files, which might help. > It sounds to me like pkg-config is simply not suitable for use with > packages that may be installed/copied anywhere. Same here. > What is the problem we are trying to solve? >From my very private POV: I'm reviewing the Find-modules we have in KDE. Many of them do if(NOT WIN32) pkgconfig stuff... endif() Now, I do not know from personal experience whether this if() make sense or not. If it does make sense, then it might make sense for any package. In that case, it would also make sense to have a global solution for this (like an option CMAKE_SKIP_PKGCONFIG_ON_WIN32), instead of having to put this if() in each and every Find-module. If the if() doesn't make sense, then it can be simply removed, and pkgconfig is used everywhere. But our Windows developers said they don't want that. OTOH, since the Find-module must also work without pkgconfig (since we cannot rely on that it exists everywhere), one could also argue that pkgconfig is unnecessary completely in Find-modules, but then another group of people starts complaining that we are ignoring existing standards and they really want to use pkgconfig. So, what I'd like to get, is first some more opinions and experiences with this, and as result some reasonable guidelines how to use pkgconfig properly (or not). 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] One project, one platform, 2 compilers
To use two different compilers, you simply need two different build trees. Same CMakeLists file, but different build trees. You should not specify the compiler in your CMakeLists.txt files at all, but rather set CC and CXX env vars to control the compiler when first generating a build tree. See the FAQ here for how to specify the compilers using CC and CXX: http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F HTH, David On Thu, Nov 17, 2011 at 11:18 AM, Paul Hansen wrote: > Hi > > I have a project that has to be compiled with two different compilers on the > same computer. > > Can I do that from the same CMakeLists.txt file? > > Specifically I am wondering: > - CMake finds a compiler and makes a test. A colleague has tried to change > the compiler variables but CMake made the test and overwrote his settings > (from the CMakeLists.txt file) in CMakeCache.txt > - With target_link_directories I can point out specifically which libraries > should be used with each executable. But what about header files? > include_directories() is not specified for each executable. Is there anyway > to control what is in the include path at different points in the > CMakeLists.txt. I have tried to use set_directory_properties(PROPERTIES > INCLUDE_DIRECTORIES "") to reset include path at one point. The deletion > works but just not at that specific point on CMakeLists.txt. > - If split up into compiler1.cmake and compiler2.cmake I still get the > include_directories() problem since values are "inherited" > > Thank you very much indeed > Paul > > -- > > 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] [RFC] How to use pkg-config under Windows (... and OSX)?
On Thu, Nov 17, 2011 at 12:26 PM, Alexander Neundorf
wrote:
> On Thursday 17 November 2011, Alan W. Irwin wrote:
>> Hi Alex:
>>
>> On 2011-11-15 18:07+0100 Alexander Neundorf wrote:
>> > Hi,
>> >
>> > cmake ships with a FindPkgConfig.cmake file, which is used by some Find-
>> > modules.
>> > Also in KDE, we have quite a lot of Find-modules which use
>> > FindPkgConfig.cmake.
>> >
>> > Now, some of them put a
>> >
>> > if(UNIX)
>> >
>> > find_package(PkgConfig)
>> >
>> > endif()
>> >
>> > around it, some use it on all platforms.
>> >
>> > In theory it works also on Windows, and also on OSX, so that this if()
>> > would not be necessary.
>> >
>> > But our (KDEs) Windows developer team says that even if pkg-config is
>> > found under Windows, and even if it reports something, they actively
>> > want to ignore it.
>> >
>> > The reason for this is that for those packages under Windows the user
>> > decides at install-time where the package will be installed, while the
>> > pc-files for pkg-config have been generated at build-time with the
>> > install directory the developer chose at build-time.
>> > This directory chosen by the developer and hardcoded into the pc-files
>> > and the actual install directory chosen by the user can very well be
>> > different.
>> >
>> > If this is the case, then pkg-config reports wrong include and wrong link
>> > directories, and the build will work worse than without pkg-config.
>> >
>> > Similar issues may exist under OSX, for libraries which are installed as
>> > a package where the user can decide at install time where to put them.
>> >
>> >
>> > So, I am looking for a, if possible, generic solution to his problem.
>> >
>> > Options I see:
>> >
>> > 1) exclude it from being used under Windows in the Find-modules:
>> > if(UNIX)
>> >
>> > find_package(PkgConfig)
>> >
>> > endif()
>> >
>> > 2) completely exclude it under Windows by putting something like the
>> > following into FindPkgConfig.cmake:
>> > if(WIN32)
>> >
>> > return()
>> >
>> > endif()
>> >
>> > 3) don't exclude it, but hope it reports good results (our Windows
>> > developers disagree)
>> >
>> > 4) add cache option whether pkg-config should be used under Windows, so
>> > something like the following would be in FindPkgConfig.cmake:
>> >
>> > if (NOT CMAKE_USE_PKGCONFIG_UNDER_WIN32)
>> >
>> > return()
>> >
>> > endif()
>> >
>> >
>> > 5) something else...
>>
>> The Linux (also Unix?) tradition is to allow some flexibility with
>> install location by allowing the user to specify at least the install
>> prefix at configuration (i.e. cmake) time. For relative install
>> paths, CMake supports this idea with CMAKE_INSTALL_PREFIX. For
>> absolute install paths, it is the responsibility of the developer of
>> the CMake-based build system to prefix the absolute install paths with
>> CMAKE_INSTALL_PREFIX. For example, that is the approach we take with
>> PLplot.
>>
>> Anyhow, if the developer of a CMake-based build system has been
>> careful to support CMAKE_INSTALL_PREFIX (either with relative install
>> paths or absolute ones that have ${CMAKE_INSTALL_PREFIX} prefixed),
>> that generally gives users all the installation location control they
>> need. For example, in PLplot all generated pkg-config files are
>> installed in an absolute location that is automatically prefixed by
>> ${CMAKE_INSTALL_PREFIX}.
>>
>> I don't completely understand the use case that you have described for
>> the KDE windows developers. If they just want their users to be able
>> to control the installation prefix, why don't they advise those users
>> to use CMAKE_INSTALL_PREFIX?
>
>
> No, this is not the issue.
> The issue is the following:
>
> Let's say package Foo (unrelated to KDE, and unrelated to cmake) has been
> ported from UNIX to Windows, and installs a pkgconfig file.
> This pkgconfig file is generated at the time when the binary package for Foo
> is generated.
>
> Now a user downloads and installs the binary package of Foo, along with the
> included pkgconfig file, which contains the install path from build time.
> But the user can now decide where he will install this binary package.
> This may differ from what is recorded in the pkgconfig file in the binary
> package of Foo.
> So the Foo.pc file is installed, and contains e.g. "C:/Foo/include", but the
> user decides to install it to "D:/MyStuff/", so the include dir would be
> "D:/MyStuff/include".
>
>
> Now cmake comes into play.
> Let's say there is a project Bar, which uses Foo, so it does
> find_package(Foo).
>
> Now FindFoo.cmake uses pkgconfig:
>
> find_package(PkgConfig)
> pkg_check_modules(Foo ...)
>
> Now this will report C:/Foo/include (because this is what the pkgconfig-file
> contains), instead of D:/MyStuff/include, where the user decided to install
> it.
>
> 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:
>
Re: [CMake] [RFC] How to use pkg-config under Windows (... and OSX)?
On Thursday 17 November 2011, Alan W. Irwin wrote:
> Hi Alex:
>
> On 2011-11-15 18:07+0100 Alexander Neundorf wrote:
> > Hi,
> >
> > cmake ships with a FindPkgConfig.cmake file, which is used by some Find-
> > modules.
> > Also in KDE, we have quite a lot of Find-modules which use
> > FindPkgConfig.cmake.
> >
> > Now, some of them put a
> >
> > if(UNIX)
> >
> > find_package(PkgConfig)
> >
> > endif()
> >
> > around it, some use it on all platforms.
> >
> > In theory it works also on Windows, and also on OSX, so that this if()
> > would not be necessary.
> >
> > But our (KDEs) Windows developer team says that even if pkg-config is
> > found under Windows, and even if it reports something, they actively
> > want to ignore it.
> >
> > The reason for this is that for those packages under Windows the user
> > decides at install-time where the package will be installed, while the
> > pc-files for pkg-config have been generated at build-time with the
> > install directory the developer chose at build-time.
> > This directory chosen by the developer and hardcoded into the pc-files
> > and the actual install directory chosen by the user can very well be
> > different.
> >
> > If this is the case, then pkg-config reports wrong include and wrong link
> > directories, and the build will work worse than without pkg-config.
> >
> > Similar issues may exist under OSX, for libraries which are installed as
> > a package where the user can decide at install time where to put them.
> >
> >
> > So, I am looking for a, if possible, generic solution to his problem.
> >
> > Options I see:
> >
> > 1) exclude it from being used under Windows in the Find-modules:
> > if(UNIX)
> >
> > find_package(PkgConfig)
> >
> > endif()
> >
> > 2) completely exclude it under Windows by putting something like the
> > following into FindPkgConfig.cmake:
> > if(WIN32)
> >
> > return()
> >
> > endif()
> >
> > 3) don't exclude it, but hope it reports good results (our Windows
> > developers disagree)
> >
> > 4) add cache option whether pkg-config should be used under Windows, so
> > something like the following would be in FindPkgConfig.cmake:
> >
> > if (NOT CMAKE_USE_PKGCONFIG_UNDER_WIN32)
> >
> > return()
> >
> > endif()
> >
> >
> > 5) something else...
>
> The Linux (also Unix?) tradition is to allow some flexibility with
> install location by allowing the user to specify at least the install
> prefix at configuration (i.e. cmake) time. For relative install
> paths, CMake supports this idea with CMAKE_INSTALL_PREFIX. For
> absolute install paths, it is the responsibility of the developer of
> the CMake-based build system to prefix the absolute install paths with
> CMAKE_INSTALL_PREFIX. For example, that is the approach we take with
> PLplot.
>
> Anyhow, if the developer of a CMake-based build system has been
> careful to support CMAKE_INSTALL_PREFIX (either with relative install
> paths or absolute ones that have ${CMAKE_INSTALL_PREFIX} prefixed),
> that generally gives users all the installation location control they
> need. For example, in PLplot all generated pkg-config files are
> installed in an absolute location that is automatically prefixed by
> ${CMAKE_INSTALL_PREFIX}.
>
> I don't completely understand the use case that you have described for
> the KDE windows developers. If they just want their users to be able
> to control the installation prefix, why don't they advise those users
> to use CMAKE_INSTALL_PREFIX?
No, this is not the issue.
The issue is the following:
Let's say package Foo (unrelated to KDE, and unrelated to cmake) has been
ported from UNIX to Windows, and installs a pkgconfig file.
This pkgconfig file is generated at the time when the binary package for Foo
is generated.
Now a user downloads and installs the binary package of Foo, along with the
included pkgconfig file, which contains the install path from build time.
But the user can now decide where he will install this binary package.
This may differ from what is recorded in the pkgconfig file in the binary
package of Foo.
So the Foo.pc file is installed, and contains e.g. "C:/Foo/include", but the
user decides to install it to "D:/MyStuff/", so the include dir would be
"D:/MyStuff/include".
Now cmake comes into play.
Let's say there is a project Bar, which uses Foo, so it does
find_package(Foo).
Now FindFoo.cmake uses pkgconfig:
find_package(PkgConfig)
pkg_check_modules(Foo ...)
Now this will report C:/Foo/include (because this is what the pkgconfig-file
contains), instead of D:/MyStuff/include, where the user decided to install
it.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to generate DEPENDS on CMake
Hello guys! There are lots of informations on internet about how to create DEPENDS on CMake, but none of them answered my question. I have a daemon being compiled very well with CMake. Now, i want to pack this binary to distribution. Once the clients have a wide variety of Linux distributions, i need to make some restrictions for my code run properly. Well, in "explicit" libraries (pthread and OpenSSL, for example) i can realize what version i need. But what about the "implicit" libraries? I mean, every code compiled in C/C++ in Linux is linked against libc and many others. Is there a way to CMake (or other tool) to generate the really complete list of dependencies of a binary? I saw that many packages in official repository make restrictions about LibC version, but even the ldd didn't tell anything about libc in my code. How they realize the minimum version required to the program run well? Thanks in advance! -- Best regards, Maurício Souza Klein. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Install command incorrectly installing archive libraries
CMake Version: 2.8 Generator: Visual Studio 2008 Problem: Two install commands are used per library. First command should only install libraries to lib/debug when the build type is Debug. The second command should only install libraries to the lib/release directory. When the build type is Debug than three libraries .lib files are being installed to the lib\release directory. For example I have the following entries for a library: INSTALL ( TARGETS first ARCHIVE DESTINATION lib/debug LIBRARY DESTINATION lib/debug RUNTIME DESTINATION lib/debug CONFIGURATIONS Debug ) INSTALL ( TARGETS first ARCHIVE DESTINATION lib/release LIBRARY DESTINATION lib/release RUNTIME DESTINATION lib/release CONFIGURATIONS Release ) So when I run cpack -C Debug and use the installer I find first.lib in both lib/debug and lib/release. I am not sure why this is the case. Any ideas? Stephen -- 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] TCL modules
I totally agree with your #2. I was thinking that it would be easier to
try and update the existing ones, rather than create new ones, at least
from the perspective of getting something done more quickly. The main
issue with that is that a new FindTclTk doesn't need to deal with backwards
compatibility. My other thought was it might be easier to become familiar
with maintaining modules by starting with existing ones, become familiar
with the whole process, and then move on to replacing the existing ones
with a new one. Ultimately a new one should be created.
On Thu, Nov 17, 2011 at 6:27 AM, Michael Hertling wrote:
> On 11/17/2011 12:28 AM, Joe Brandt wrote:
> > I have a couple issues, that I'd like to help fix, with the current
> > FindTCL.cmake, FindTclsh.cmake, FindWish.cmake, and FindTclStub.cmake
> that
> > make them unusable for me. The first is they do not always find the
> > various components from the same Tcl installation on the system. The
> > second being that you cannot specify the version of Tcl that you want to
> > find via the find_package command. I have systems that have multiple
> > installations of Tcl and have programs that require different versions of
> > Tcl.
> >
> > I have modified the current Tcl modules to solve these two issues. My
> > changes at this point were geared around changing as little as possible
> > from the originals to get these two items to work. I really needed to
> just
> > get it working for my environment, but after thinking about it I would
> > rather try and get these changes/ideas pushed upstream rather than have
> to
> > maintain my own Tcl modules.
> >
> > I do not see a maintainer for these modules. I also saw there was
> > discussions around the Tcl modules a year ago, but don't know if that
> > panned out into anything. If there is no maintainer I am certainly
> willing
> > to maintain these if it means these changes, in some form or another, can
> > get incorporated back upstream.
> >
> > Joe
>
> Two remarks:
>
> (1) IIRC, the main obstacle w.r.t. version selection in the TCL modules
> - as well as the Python and certainly further ones, BTW - is the find
> functions' current inability to search for patterns, e.g. you can't
> have FIND_LIBRARY() to search for libtcl\.[0-9]+\.[0-9]+\.so. Thus,
> IMO, the key for a reasonable support of version selection by find
> modules in general is the addition of pattern matching abilities
> to the FIND_{LIBRARY,PROGRAM,PATH,FILE}() commands, cf. [1].
>
> (2) IMO, the TCL-related stuff - as well as the Python one, BTW - is a
> perfect candidate for a comprehensive and component-aware find module
> FindTclTk.cmake, providing components tcl, tk, wish etc., so why not
> pouring the time, work and brainpower into the development of such a
> module instead of bothering about a bunch of separate modules which
> actually belong together? Moreover, having the seach for libraries,
> headers and executables centralized in one module only would make it
> *much* easier to ensure a consistency w.r.t. the components' versions.
>
> Regards,
>
> Michael
>
> [1] http://public.kitware.com/Bug/view.php?id=8396
> --
>
> 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] Visual Studio 2010 generator: Linking static libraries to one dll problem (Use Library Dependency Inputs)
On 17 November 2011 16:30, Matthias Wieding-Drewes wrote: > > I'am currently in the process of converting a Visual Studio 2010 project > to CMake. There are three (sub) projects each of which results in a > staticaly linked library. This libraries are then combined into a > single .dll file. > > Well actually that's how it should be (and is set up in CMake). > > The .dll does not contain any symbols since VS 2010 does not realy read > the static libraries. You may want to learn it is a bad idea to link N static libraries into single shared, especially on Windows: http://www.cmake.org/pipermail/cmake/2010-November/040869.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Visual Studio 2010 generator: Linking static libraries to one dll problem (Use Library Dependency Inputs)
Hallo, I'am currently in the process of converting a Visual Studio 2010 project to CMake. There are three (sub) projects each of which results in a staticaly linked library. This libraries are then combined into a single .dll file. Well actually that's how it should be (and is set up in CMake). The .dll does not contain any symbols since VS 2010 does not realy read the static libraries. It works if (in the reference tab of the dll target) for each subproject "Use Library Dependency Inputs" is used. And here comes the question: Is there a way to instruct the VS 2010 generator to set this setting. With best regards Matthias Wieding-Drewes -- 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] One project, one platform, 2 compilers
Hi I have a project that has to be compiled with two different compilers on the same computer. Can I do that from the same CMakeLists.txt file? Specifically I am wondering: - CMake finds a compiler and makes a test. A colleague has tried to change the compiler variables but CMake made the test and overwrote his settings (from the CMakeLists.txt file) in CMakeCache.txt - With target_link_directories I can point out specifically which libraries should be used with each executable. But what about header files? include_directories() is not specified for each executable. Is there anyway to control what is in the include path at different points in the CMakeLists.txt. I have tried to use set_directory_properties(PROPERTIES INCLUDE_DIRECTORIES "") to reset include path at one point. The deletion works but just not at that specific point on CMakeLists.txt. - If split up into compiler1.cmake and compiler2.cmake I still get the include_directories() problem since values are "inherited" Thank you very much indeed Paul -- 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 a new language
On 11/16/2011 4:03 PM, Alan W. Irwin wrote: Hi Bill: Your summary shows you misunderstood what I said so I have to correct that. The basic issue I have with your interpretation is "additional generic language support" != "Creating a generic way to add new languages" OK, let me try again. Adding any new feature to CMake, that will work on all platforms is a pretty huge task, and will require some serious funding, or someone with lots of free time and skill. I do not see any low hanging fruit or easy to do things in what you are asking for. Perhaps other developers will. The Fortran support was funded by a group at Sandia labs, and was implemented over many months of effort. It is also a slighty different beast as the IDE's like VS can have Fortran support. So, coming up with a makefile only solution can work with the IDE as well. ADA and OCaml do not have the same IDE support. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] shell level access to values of cmake variables
On 11/10/2011 06:48 PM, vagn scott wrote:
>
>
> in my CMakeLists.txt file I have a statement
>
> project(hello_foo_baz)
>
> This defines PROJECT_NAME among other things.
>
> is there something like
>
> cmake --dump-var PROJECT_NAME
>
> that would output the string
>
> hello_foo_baz
>
> TIA,
>
> vagn
PROJECT_NAME is a CMake variable, i.e. it exists while the CMake
process is running, and it's visible in the CMakeLists.txt files
by the usual ${} dereferencer. It is *not* a member of the CMake
process' environment, although it can be written to the latter:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(ENVVAR NONE)
MESSAGE("BEFORE:")
EXECUTE_PROCESS(COMMAND env COMMAND grep PROJECT_NAME)
SET(ENV{PROJECT_NAME} ${PROJECT_NAME})
MESSAGE("AFTER:")
EXECUTE_PROCESS(COMMAND env COMMAND grep PROJECT_NAME)
In no case it is written to the environment of the CMake process'
parent, e.g. the shell, i.e. you can not access a PROJECT_NAME
environment variable after the CMake process has terminated.
If you need to access PROJECT_NAME after the configuration
has finished, the CMakeLists.txt must preserve it, e.g.
CONFIGURE_FILE(project_name.txt.in project_name.txt @ONLY)
with a project_name.txt.in like "@PROJECT_NAME@".
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Circular dependencies because of file names?
On 11/16/2011 06:36 PM, Jookia wrote:
> I've actually used that workaround, but it seems dirty as it shows up in
> IDE targets like Visual Studio or other IDEs or makefiles. In fact, I
> kind of like the 'generating /docs' part of the makefile.
>
> Would it just be smarter to rename the target to 'documentation'?
Of course, that's also possible, but then, the documentation target and
the documentation directory would not be named the same. Alternatively,
you might leave out the WORKING_DIRECTORY clause, add another COMMAND
"cmake -E make_directory" to the target and use "cmake -E chdir":
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(DOCS NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_CUSTOM_TARGET(docs
COMMAND ${CMAKE_COMMAND} -E
make_directory ${CMAKE_BINARY_DIR}/docs
COMMAND ${CMAKE_COMMAND} -E
chdir ${CMAKE_BINARY_DIR}/docs pwd)
Presumably, the directory's additional creations carries no weight.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] TCL modules
On 11/17/2011 12:28 AM, Joe Brandt wrote:
> I have a couple issues, that I'd like to help fix, with the current
> FindTCL.cmake, FindTclsh.cmake, FindWish.cmake, and FindTclStub.cmake that
> make them unusable for me. The first is they do not always find the
> various components from the same Tcl installation on the system. The
> second being that you cannot specify the version of Tcl that you want to
> find via the find_package command. I have systems that have multiple
> installations of Tcl and have programs that require different versions of
> Tcl.
>
> I have modified the current Tcl modules to solve these two issues. My
> changes at this point were geared around changing as little as possible
> from the originals to get these two items to work. I really needed to just
> get it working for my environment, but after thinking about it I would
> rather try and get these changes/ideas pushed upstream rather than have to
> maintain my own Tcl modules.
>
> I do not see a maintainer for these modules. I also saw there was
> discussions around the Tcl modules a year ago, but don't know if that
> panned out into anything. If there is no maintainer I am certainly willing
> to maintain these if it means these changes, in some form or another, can
> get incorporated back upstream.
>
> Joe
Two remarks:
(1) IIRC, the main obstacle w.r.t. version selection in the TCL modules
- as well as the Python and certainly further ones, BTW - is the find
functions' current inability to search for patterns, e.g. you can't
have FIND_LIBRARY() to search for libtcl\.[0-9]+\.[0-9]+\.so. Thus,
IMO, the key for a reasonable support of version selection by find
modules in general is the addition of pattern matching abilities
to the FIND_{LIBRARY,PROGRAM,PATH,FILE}() commands, cf. [1].
(2) IMO, the TCL-related stuff - as well as the Python one, BTW - is a
perfect candidate for a comprehensive and component-aware find module
FindTclTk.cmake, providing components tcl, tk, wish etc., so why not
pouring the time, work and brainpower into the development of such a
module instead of bothering about a bunch of separate modules which
actually belong together? Moreover, having the seach for libraries,
headers and executables centralized in one module only would make it
*much* easier to ensure a consistency w.r.t. the components' versions.
Regards,
Michael
[1] http://public.kitware.com/Bug/view.php?id=8396
--
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] find_library and static library
On 11/17/2011 10:28 AM, Romain LEGUAY wrote: > Hello everyone! > I found in previous message there is none option to specify to > find_library function to search just static library. It was for CMake 2.6. > > Has it got any change with the new version of CMake? AFAIK, it hasn't, since the root of this issue is still that there's no generally accepted naming convention for actual static libraries and the DLL-accompanying import libraries on Windows. However, on *nix, you might make FIND_LIBRARY() prefer static libaries by manipulating the CMAKE_FIND_LIBRARY_SUFFIXES variable. > I try to specify the name of the library like this: > > find_library(MY_STATIC_LIB NAMES libmylib.a PATHS /path/to/mylib) > > but it doesn't work. > > I don't understand the reason why it doesn't work. > > If anyone have some ideas... Usually, specifying the library's full name should work. Could you provide a minimal but complete counter-example for investigation? Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Problems with CPack/NSIS and CPACK_NSIS_MUI_FINISHPAGE_RUN
Hi,
the
issue (http://public.kitware.com/Bug/view.php?id=11144)
is already closed but the problem still exists.
If I use
the following:
SET(CPACK_NSIS_MUI_FINISHPAGE_RUN
"${PROJECT_NAME}.exe")
Then the
file project.nsi contains the following string and the application isn’t
launched:
!define MUI_FINISHPAGE_RUN
"$INSTDIR\bin\MyProject"
If I use
the following string instead to temporary fix the issue:
SET(CPACK_NSIS_MUI_FINISHPAGE_RUN
"..${PROJECT_NAME}.exe")
Then the
file contains:
!define MUI_FINISHPAGE_RUN "$INSTDIR\bin\..\MyProject"
With this
the Application is launched successfully.
Any hints
to avoid the “dirty” hack?
Best
Regards
NoRulez
--
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] Problems with CPack/NSIS and CPACK_NSIS_MUI_FINISHPAGE_RUN
Hi,
the issue (http://public.kitware.com/Bug/view.php?id=11144) is already
closed but the problem still exists.
If I use the following:
SET(CPACK_NSIS_MUI_FINISHPAGE_RUN "${PROJECT_NAME}.exe")
Then the file project.nsi contains the following string and the application
isnt launched:
!define MUI_FINISHPAGE_RUN "$INSTDIR\bin\MyProject"
If I use the following string instead to temporary fix the issue:
SET(CPACK_NSIS_MUI_FINISHPAGE_RUN "..${PROJECT_NAME}.exe")
Then the file contains:
!define MUI_FINISHPAGE_RUN "$INSTDIR\bin\..\MyProject"
With this the Application is launched successfully.
Any hints to avoid the dirty hack?
Best Regards
NoRulez
--
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 Link Dependencies
From: Andreas Pakulat Sent: 16 November 2011 19:50 >> I'm just starting to use the cpack module in cmake to put together TGZ. >> >> I use TARGET_LINK_LIBRARIES to specify which libs to use during linking. >> >> Is there a way to get a list of the libs that are found and include them in >> my TGZ? >> >> I can include the libs that are compiled as part of my build, but I also >> want to include the 3rd party libs as well. > Look at the BundleUtilities module, that'll allow you to create a > self-contained application package. Thanks Andreas, I'll give that a go. Regards, Marcus *** IMPORTANT NOTICE *** This message (including any attachments) is confidential and is for the intended recipient only. If you are not the intended recipient, please inform the sender and delete any copies from your system. Internet communications are not secure and therefore Winterflood Securities Ltd does not accept legal responsibility for any of its contents (including any attachments) and any view expressed by the sender as these are not necessarily the views of Winterflood Securities Ltd. Although all emails sent and received by Winterflood Securities Ltd are passed through extensive virus scanning technologies, we cannot guarantee the email (including attachments) is virus free. You should take whatever measures you deem appropriate within your organisation to ensure maximum protection. Registered Office: The Atrium Building, Cannon Bridge, 25 Dowgate Hill, London, EC4R 2GA. Registered in England No. 2242204. Winterflood Securities Limited is authorised and regulated by the Financial Services Authority. -- 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] find_library and static library
Hello everyone! I found in previous message there is none option to specify to find_library function to search just static library. It was for CMake 2.6. Has it got any change with the new version of CMake? I try to specify the name of the library like this: find_library(MY_STATIC_LIB NAMES libmylib.a PATHS /path/to/mylib) but it doesn't work. I don't understand the reason why it doesn't work. If anyone have some ideas... Thanks, Romain -- 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
