Re: [CMake] Problem with LINK_DIRECTORIES

[Michael Hertling]

On 11/14/2011 09:15 PM, Robert Dailey wrote:
> On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling wrote:
> 
>> On 11/14/2011 06:17 PM, Robert Dailey wrote:
>>> Well maybe you can tell me I'm doing this wrong then, but based on how I
>> am
>>> currently setting up my third party libraries, it is required.
>>>
>>> So basically all third party libraries we use are not installed
>>> individually, instead we have a server on our intranet that contains
>>> precompiled versions of all libraries in a specific and consistent
>>> hierarchy. For this reason, it doesn't make sense to use find_library(),
>>> which would normally always give you absolute paths to your library files
>>> and thus link_directories() would not be needed.
>>>
>>> Instead I have a script in CMake that iterates each third party library
>> and
>>> adds its lib link directory to a list. When done I take this whole list
>> of
>>> link directories and pass it to link_directories() in my top level
>>> CMakeLists file, this way each and every project will include all of the
>>> third party library lib directories to have access to them.
>>
>> Instead of populating a list with the libraries' directories, you might
>> set up one variable for each library containing the latter's full path,
>> e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
>> CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
>> files and, thus, will be known wherever they are needed in your project.
>>
>>> For each target I simply create a list of my libs, like so:
>>>
>>> set( libraries zlib libbdb47 )
>>
>> SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
>>
>>> I pass each one of these to target_link_libraries() and I leave it up to
>>> the compiler to search for where to find the file in the provided link
>>> directories.
>>
>> An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
>> especially with numerous directories, there's a growing probability
>> that the -L option will lure the linker into a wrong directory some
>> day. There're even situations which can't be resolved with -L/-l at
>> all: Suppose you have a directory x with liba.so and libb.so, and a
>> directory y with different versions of lib{a,b}.so. Suppose further
>> you want to link against x/liba.so and y/libb.so. How do you achieve
>> this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
>> insisting on the use of LINK_DIRECTORIES() limits the possibilities
>> how to organize the libraries on your intranet server. IMO, these
>> are actual drawbacks. OTOH, you must know the libaries' locations
>> to use LINK_DIRECTORIES(), and the libraries must be known anyway,
>> so why not join the locations to the libraries and use full paths?
> 
> 
> Problem is, if I end up using find_library(), I will have to provide hint
> search directories for each and every single library, and there are about
> 20 of them. This to me is the same as just generating a list of directories
> and including those directly, and a lot less trouble.

As David has outlined in the meantime, the advice is not about using
FIND_LIBRARY() - which has not been mentioned a single time - but to
assemble full paths from the libraries' directories and the libraries
themselves, instead of collecting the directories and passing them to
LINK_DIRECTORIES(). I doubt that the latter really means less trouble.

> find_library() is great and I really wanted to use it for this, but to me
> the benefits of using it diminish when we are not using third party
> libraries installed in a non deterministic location. If a user installs the
> third party libraries in different locations on each of their machines, and
> different versions, it makes more sense to use it in that case.

Even if your third-party libraries' organization isn't subject to
change, so you don't need to use FIND_LIBARRY(), you might set up
variables with the libraries' full paths in the cache, i.e. using
SET(... CACHE FILEPATH ...), and preferably initialize them with
a separate file and the -C option. In this way, you do not need
to hard-code any paths in your project, and the user gains the
chance to manipulate each path on the command line or the GUI.

> Why should I let CMake search & find a library when I already know where it
> is? Simply to get absolute paths to those libraries? If I want absolute
> paths I can think of much better ways to do it, preferably through string
> concatenation.

Exactly; do this to get full paths to your libraries, use these paths
in TARGET_LINK_LIBRARIES() and eliminate LINK_DIRECTORIES() from your
project. Besides, "knowing where it is" means an assumption of your
project on your system's administrational/organizational setup, and
relying on such an assumption means that you can't change this setup
without risking your project's breakage. Finally, LINK_DIRECTORIES()
dramatically increases this risk because it makes your project subtly
vunerable to changes in the third-party libraries' directory 

[CMake] Custom command behavior

[Alexander Broekhuis]

Hi all,

When using a custom command in a macro I see some strange behavior.

The following setup is used:
I have a macro, called "bundle", in this macro a custom command is added.
This command uses a library as target, and executes cpack with a
configuration. I use cpack to create a zip file inside my project with the
library and additional resources.

This macro is used with the name of a library. When running the library
target (make {lib-name}), the command is executed for all usages of the
macro, instead of only for the given target. If I change it to a custom
target, and add that target to the library target using add_dependencies it
is all ok, but a custom target is always out-of-date, which is something I
would like to prevent.

If I run the cpack command myself it is only executed once (as expected).

What am I doing wrong here?

TiA!

ps: The macro I use:

macro(bundle)
 PARSE_ARGUMENTS(BUNDLE "FILES;DIRECTORIES" "" ${ARGN})
  LIST(GET BUNDLE_DEFAULT_ARGS 0 BUNDLE_NAME)
  SET(__bundleConfig
${CMAKE_CURRENT_BINARY_DIR}/CPackConfig-${BUNDLE_NAME}-bundle.cmake)
  CONFIGURE_FILE(${PROJECT_SOURCE_DIR}/cmake/CPackConfig.in
${__bundleConfig} @ONLY)

  ADD_CUSTOM_COMMAND(TARGET ${BUNDLE_NAME}
POST_BUILD
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/bundles

# This is an echo of the command. Running this myself on the command
line works as expected
COMMAND echo ${BUNDLE_NAME} ${CPACK_COMMAND} --config
"${__bundleConfig}"

# This is executed for each macro call I did
COMMAND ${CPACK_COMMAND} --config "${__bundleConfig}"
  )
endmacro(bundle)

--
Met vriendelijke groet,

Alexander Broekhuis
--

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] [ANN] OSEHRA Debuts Weekly Teleconference Tomorrow

[Lisa Avila]

The Open Source Electronic Health Record Agent (OSEHRA) will start a
weekly teleconference to discuss the current set of OSEHRA software
development tools on Wednesday, November 16 from 3:30pm to 4:30pm EST.
This first meeting will provide an introduction to the many software
development tools that are now available for VistA/M developers from
the www.osehra.org website. This includes OSEHRA’s:

Source Code Repository based on Git (http://code.osehra.org/gitweb)
Software Quality Dashboard based on CDash
(http://code.osehra.org/CDash/index.php?project=Open+Source+EHR)
Automated Vista/M Manual Pages (http://code.osehra.org/dox)
Code Review Tool based on Gerrit (http://review.code.osehra.org)
Technical Journal for submission of large code contributions
(http://code.osehra.org/journal)
Bug and Feature Tracker (http://issues.osehra.org)
Architecture Reference (http://architecture.osehra.org)

This first weekly meeting of OSEHRA’s Development Tools group will be
conducted as a live webinar. To register for this event you will need
to visit: https://www3.gotomeeting.com/register/392269830 and register
by providing your name and email address. Please note that GoToWebinar
is only compatible with Windows or Macs, and does not work with Linux
machines. For further details on the systems requirements, please
visit the GoToWebinar site here.

We hope that you will be able to join this event and contribute your
ideas and thoughts on how we can improve the tools and resources
available from www.osehra.org.

-OSEHRA Development Tools Team
--

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?

[Michael Hertling]

On 11/14/2011 09:31 PM, Jookia wrote:
> I have the following code:
> 
> # -- DOXYGEN
> 
> find_package(Doxygen)
> 
> set(docsDir "${CMAKE_BINARY_DIR}/docs/")
> 
> add_custom_command(OUTPUT ${docsDir}
>COMMAND ${CMAKE_COMMAND} "-E" "make_directory"
>${docsDir} VERBATIM)
> 
> add_custom_target("docs"
>COMMAND "${DOXYGEN_EXECUTABLE}"
>"${CMAKE_SOURCE_DIR}/../doxygen/doxyfile"
>WORKING_DIRECTORY ${docsDir}
>DEPENDS ${docsDir})
> 
> set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
>"${docsDir}")
> 
> Which causes a circular conflict. But when I change the docsDir to 
> "${CMAKE_BINARY_DIR}/docs2/", I no longer get the error.
> 
> Is there a way to fix this?

The "docs" custom command is integrated in the "docs" custom target's
Makefile with a relative path, so there are dependencies of the type
"docs" (custom target) on "docs" (custom command's output) which are
ignored by Make. Thus, the "docs" directory is not created, and the
custom target fails. In general, it's a bad idea to have targets
with the same name as files/directories they depend on.

In order to solve this issue, add another custom target, say, docdir
which depends on the custom command's output; this will decouple the
"docs" custom target from the custom command. Finally, establish the
dependency of "docs" on "docdir" by ADD_DEPENDENCIES():

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(DOCS NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/docs
COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_BINARY_DIR}/docs)
ADD_CUSTOM_TARGET(docdir DEPENDS ${CMAKE_BINARY_DIR}/docs)
ADD_CUSTOM_TARGET(docs
COMMAND ${CMAKE_COMMAND} -E echo "custom target docs"
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/docs)
ADD_DEPENDENCIES(docs docdir)

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] Problem with LINK_DIRECTORIES

[Robert Dailey]

On Tue, Nov 15, 2011 at 4:49 AM, Michael Hertling wrote:
>
> As David has outlined in the meantime, the advice is not about using
> FIND_LIBRARY() - which has not been mentioned a single time - but to
> assemble full paths from the libraries' directories and the libraries
> themselves, instead of collecting the directories and passing them to
> LINK_DIRECTORIES(). I doubt that the latter really means less trouble.
>

I mentioned find_library() because I have used it in the past to obtain
absolute paths to my third party libraries and it worked very well. It's a
solution to the problem, so I don't see any problem in talking about it.

Exactly; do this to get full paths to your libraries, use these paths
> in TARGET_LINK_LIBRARIES() and eliminate LINK_DIRECTORIES() from your
> project. Besides, "knowing where it is" means an assumption of your
> project on your system's administrational/organizational setup, and
> relying on such an assumption means that you can't change this setup
> without risking your project's breakage. Finally, LINK_DIRECTORIES()
> dramatically increases this risk because it makes your project subtly
> vunerable to changes in the third-party libraries' directory hierarchy.
>

The setup I have chosen to eliminate link_directories() involves globbing
everything in each library's 'lib' directory and storing that in an alias,
such as 'openssl'. When a project specifies this alias, it looks into the
openssl_THIRD_PARTY_LIBS internal cache variable which is created by the
third-party lookup system I created. The globbed *.lib files will be listed
in that cache variable and can be added via target_link_libraries(). All of
this happens behind the scenes, all the user needs to specify in the
project CMakeLists files is 'openssl' to get those libs.

Depending on a simple and consistent structure on a NAS for our third party
libraries isn't a big deal and won't change. The only change it will endure
is when we add new libraries. The structure is like so:

\\nas\third_party\openssl\1.0\msvc71\debug\lib (there is also 'include' and
'bin')

This way of including libs works great for what we do. It's simple and
mostly automated & transparent.

When considering libraries that have a LOT of libs, and you don't want to
blindly include them all, we simply code special logic in our core CMake
files to handle those differently. For example, consider boost. If the user
specifies the third party library 'boost', it will include over 20 libs for
all of the different components. Instead, I have a syntax like so:

boost_filesystem

In this case I strip out the "boost_" part, leaving "filesystem", and I
append that to whatever our boost library format is, like so: boost_{0}.lib
and make a full path to that, pass it to target_link_libraries().

I don't like the core CMake module knowing about specific third party
libraries and having logic for them, but I may abstract this out later into
some sort of generic logic where the definitions are stored in a separate
file.
--

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] Custom command behavior

[Alexander Broekhuis]

Hello,

I think I've already found the problem. In the custom command I run a CPack
script, and CPack triggers a full build of the project, which in turn again
triggers the custom command (and thus the CPack command).

Is it possible to make the CPack config so that only a specific target is
being build? I have a one on one relation between library and zip file, and
would like to be able to build one target and resulting zipfile.

Currently I am using a custom target, this also solves my problem, and
would be fine if it didn't build always. Is it possible to add some
up-to-date check to it?

2011/11/15 Alexander Broekhuis 

> Hi all,
>
> When using a custom command in a macro I see some strange behavior.
>
> The following setup is used:
> I have a macro, called "bundle", in this macro a custom command is added.
> This command uses a library as target, and executes cpack with a
> configuration. I use cpack to create a zip file inside my project with the
> library and additional resources.
>
> This macro is used with the name of a library. When running the library
> target (make {lib-name}), the command is executed for all usages of the
> macro, instead of only for the given target. If I change it to a custom
> target, and add that target to the library target using add_dependencies it
> is all ok, but a custom target is always out-of-date, which is something I
> would like to prevent.
>
> If I run the cpack command myself it is only executed once (as expected).
>
> What am I doing wrong here?
>
> TiA!
>
> ps: The macro I use:
> 
> macro(bundle)
>  PARSE_ARGUMENTS(BUNDLE "FILES;DIRECTORIES" "" ${ARGN})
>   LIST(GET BUNDLE_DEFAULT_ARGS 0 BUNDLE_NAME)
>   SET(__bundleConfig
> ${CMAKE_CURRENT_BINARY_DIR}/CPackConfig-${BUNDLE_NAME}-bundle.cmake)
>   CONFIGURE_FILE(${PROJECT_SOURCE_DIR}/cmake/CPackConfig.in
> ${__bundleConfig} @ONLY)
>
>   ADD_CUSTOM_COMMAND(TARGET ${BUNDLE_NAME}
> POST_BUILD
> WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/bundles
>
> # This is an echo of the command. Running this myself on the command
> line works as expected
> COMMAND echo ${BUNDLE_NAME} ${CPACK_COMMAND} --config
> "${__bundleConfig}"
>
> # This is executed for each macro call I did
> COMMAND ${CPACK_COMMAND} --config "${__bundleConfig}"
>   )
> endmacro(bundle)
> 
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>



-- 
Met vriendelijke groet,

Alexander Broekhuis
--

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] Libraries with custom build command

[Michael Hertling]

On 11/14/2011 08:11 PM, Mathias Gaunard wrote:
> What is the recommended way to define libraries with custom build commands?
> 
> This trick seems to be the only way:
> 
> if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp)
>file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp)
> endif()
> add_library(foo dummy.cpp)
> add_custom_command(TARGET foo POST_BUILD
> COMMAND my command to replace the dummy libfoo
>)
> 
> Is it normal that kind of thing is not possible with IMPORTED libraries?

IMO, no: ;-)

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CUSTOMLIBRARIES C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/libf.so
COMMAND gcc -fPIC -c f.c
COMMAND gcc -fPIC -shared -o libf.so f.o
DEPENDS ${CMAKE_BINARY_DIR}/f.c)
ADD_CUSTOM_TARGET(libf DEPENDS ${CMAKE_BINARY_DIR}/libf.so)
ADD_LIBRARY(f SHARED IMPORTED)
SET_TARGET_PROPERTIES(f PROPERTIES
IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/libf.so)
ADD_DEPENDENCIES(f libf)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main f)

Does this suit your needs?

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] cmake 2.8.6 On Linux , link error and added headers to ..._EXTERNAL_OBJECTS for executables

[Michael Hertling]

On 11/12/2011 12:41 AM, david_bjorn...@agilent.com wrote:
> I'm getting a Link error on Linux when I use CMake 2.8.6 or 2.8.5.  If use 
> CMake 2.6.3, with the exact same configuration, the link works.
> 
> I did a diff on the build.make from 2.8.6 and 2.6.3 and found  when I use 
> cmake 2.8.6 On Linux  adding headers to ..._EXTERNAL_OBJECTS  for executables 
> under the build.make.
> 
> The following is the link error I get, it looks for a header but, the 
> link.txt does need it and the diff on build.make that looks like is causing 
> this.
> 
> Link Error Message
> 
> 
> nux_x86_64/lib/libeemdump.so 
> /hped/builds/tools/google-breakpad/784/lib.linux_x86_64/release/libbreakpad.a 
> /hped/builds/tools/google-breakpad/78
> 4/lib.linux_x86_64/release/libbreakpad_client.a 
> /hped/builds/tools/google-breakpad/784/lib.linux_x86_64/release/libbreakpad_server.a
>  /gfs/sr/blu
> efin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/lib/libplugin_manager.so
>  /hped/builds/tools/qt/4.7.4/linux_x86_6
> 4/lib/libQtCore.so 
> /hped/builds/tools/cryptopp/5.6.0_0/linux_x86_64/release/libcryptopp.a 
> /hped/builds/tools/boost/boost_1_45_0/lib.linux_x86_64
> /release/libboost_date_time.a 
> /hped/builds/tools/boost/boost_1_45_0/lib.linux_x86_64/release/libboost_filesystem.a
>  /hped/builds/tools/boost/boos
> t_1_45_0/lib.linux_x86_64/release/libboost_program_options.a 
> /hped/builds/tools/boost/boost_1_45_0/lib.linux_x86_64/release/libboost_system.a
>  /h
> ped/builds/tools/boost/boost_1_45_0/lib.linux_x86_64/release/libboost_thread.a
>  /hped/builds/tools/stl/5.2.1/lib.linux_x86_64/libstlport_gcc.so -
> Wl,-rpath,/hped/builds/tools/qt/4.7.4/linux_x86_64/lib:/hped/builds/tools/stl/5.2.1/lib.linux_x86_64:/gfs/sr/bluefin/d1/build/hped/builds/sr/dev
> XXX/rcupgrd_int/build/64bitrelease/linux_x86_64/lib:/release:
> msgs_eesofpvm_multitool.h:4:19: fatal error: Diag.h: No such file or directory
> compilation terminated.
> make[3]: *** 
> [/gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool]
>  Error 1
> make[3]: Leaving directory 
> `/hfs/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease'
> make[2]: *** 
> [projects/simsys/source/eesofpvm_multitool/CMakeFiles/eesofpvm_multitool.dir/all]
>  Error 2
> 
> 
> Diff with the build.make file, notice the file msgs_eesofpvm_multitool.h
> 
> 
> < eesofpvm_multitool_EXTERNAL_OBJECTS =
> ---
>> eesofpvm_multitool_EXTERNAL_OBJECTS = \
>> "/hfs/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/projects/simsys/source/eesofpvm_multitool/msgs_eesofpvm_multitool.h"
> 498d482
> < 
> /gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool:
>  /hped/builds/tools/qt/4.7.4
> /linux_x86_64/lib/libQtCLucene.so
> 500,502d483
> < 
> /gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool:
>  /usr/X11R6/lib64/libXext.so
> < 
> /gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool:
>  /usr/X11R6/lib64/libX11.so
> < 
> /gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool:
>  /usr/lib64/libm.so
> 519a501
>> /gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool:
>>  projects/simsys/source/eeso
> fpvm_multitool/msgs_eesofpvm_multitool.h
> 
> 
> ++David->Bjornbak;

Could you boild down this issue to a minimal and self-sufficient example
- i.e. a project working with 2.6 (quite old) but failing with 2.8 - and
post it here for further 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

Re: [CMake] cmake 2.8.6 On Linux , link error and added headers to ..._EXTERNAL_OBJECTS for executables

[Bill Hoffman]

On 11/15/2011 11:52 AM, Michael Hertling wrote:


Could you boild down this issue to a minimal and self-sufficient example
- i.e. a project working with 2.6 (quite old) but failing with 2.8 - and
post it here for further investigation?

There was a bug created for this, and the problem found.  The cmake code 
was marking the .h file as an object file.  Must have been a bug fix in 
CMake that allowed the .h to be treated as an object file.


See here for information:
http://public.kitware.com/Bug/view.php?id=12575


-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

[CMake] [RFC] How to use pkg-config under Windows (... and OSX) ?

[Alexander Neundorf]

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...

Comments ?


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] How to build ccmake.exe on Windows?

[Bill Hoffman]

On 11/11/2011 3:21 PM, Robert Dailey wrote:

I'm using Cygwin with the MSVC toolchain and I need ccmake.exe. I can't
use the one from the Cygwin package manager because it's older than the
version I'm using. I'd like to build it myself through Visual Studio
like I did with cmake and cmake-gui if possible. Any help?



If you are using the MSVC toolchain, you can not use the cygwin built 
cmake.  That one only works with the cygwin toolchain.  You want the 
windows binaries from www.cmake.org.


-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] cmake 2.8.6 On Linux , link error and added

[david_bjornbak]

The issue has been resolved


http://public.kitware.com/Bug/view.php?id=12575


++David->Bjornbak;

--

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) ?

[Rolf Eike Beer]

Am Dienstag, 15. November 2011, 18:07:16 schrieb Alexander Neundorf:

> 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.

> 5) something else...
> 
> Comments ?

Fix the installers to write the install paths into the .pc files?

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

Re: [CMake] [RFC] How to use pkg-config under Windows (... and OSX)?

[Alexander Neundorf]

On Tuesday 15 November 2011, Rolf Eike Beer wrote:
> Am Dienstag, 15. November 2011, 18:07:16 schrieb Alexander Neundorf:
> > 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.
> > 
> > 5) something else...
> > 
> > Comments ?
> 
> Fix the installers to write the install paths into the .pc files?

While correct, this doesn't help anybody who has to deal with these files now.

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] How to build ccmake.exe on Windows?

[Bill Hoffman]

On 11/15/2011 12:59 PM, Robert Dailey wrote:

The windows binaries unfortunately do not contain ccmake.exe.



You have to use cmake-gui.  There is no version of ccmake that will work 
for  what you want to do, sorry...


-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] How to build ccmake.exe on Windows?

[Robert Dailey]

The windows binaries unfortunately do not contain ccmake.exe.

-
Robert Dailey


On Tue, Nov 15, 2011 at 11:24 AM, Bill Hoffman wrote:

> On 11/11/2011 3:21 PM, Robert Dailey wrote:
>
>> I'm using Cygwin with the MSVC toolchain and I need ccmake.exe. I can't
>> use the one from the Cygwin package manager because it's older than the
>> version I'm using. I'd like to build it myself through Visual Studio
>> like I did with cmake and cmake-gui if possible. Any help?
>>
>
>
> If you are using the MSVC toolchain, you can not use the cygwin built
> cmake.  That one only works with the cygwin toolchain.  You want the
> windows binaries from www.cmake.org.
>
> -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
>
--

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] Issues with finding raptor in the soprano build

[Laszlo Papp]

Hi,

I am now having issues with finding the raptor software for the build
of the soprano project on Harmattan (N9 OS and distribution). It works
on desktop and in scratchbox. It does not work in qemu though.

It looks weird because redland was found properly, and the those
find_package lines are residing after each other:
http://quickgit.kde.org/?p=soprano.git&a=blob&h=61aa37db11b2091f4d9dbb822bbe8eecf56e543e&hb=1f6789719c53d964e2c8e705330e043dc04f2806&f=CMakeLists.txt#143

You can find the FindRaptor.cmake module here:
http://quickgit.kde.org/?p=soprano.git&a=blob&h=c5043c8bef5306d847dae3bc511d18b2230ee453&hb=1f6789719c53d964e2c8e705330e043dc04f2806&f=cmake/modules/FindRaptor.cmake

I think this is a bit closer to the issue:
-- [TEST-BEGIN] - FIND_PACKAGE RAPTOR2.0.4
-- VERSION_VAR  (missing:  REQUIRED_VARS)
-- [TEST-END] - FIND_PACKAGE RAPTOR2.0.4

for this debugging lines in the CMakeLists.txt file:
 message(STATUS "[TEST-BEGIN] - FIND_PACKAGE RAPTOR2.0.4")
 find_package(Raptor 2.0.4)
 message(STATUS "[TEST-END] - FIND_PACKAGE RAPTOR2.0.4")

Also:
I debugged it further on, and it enters this if condition, too:
http://quickgit.kde.org/?p=soprano.git&a=blob&h=c5043c8bef5306d847dae3bc511d18b2230ee453&hb=1f6789719c53d964e2c8e705330e043dc04f2806&f=cmake/modules/FindRaptor.cmake#154

Also:
I have this file on my system: /usr/include/raptor2/raptor.h (That is
the one the FindRaptor.cmake module is looking for iirc).

Thank you in advance! I am now really stuck here.

Best Regards,
Laszlo Papp
--

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] Issues with finding raptor in the soprano build

[Laszlo Papp]

I have tried to grab more debug outputs, and here are my relevant printouts:

statusPC_RAPTOR2_LIBDIR: /usr/lib
statusPC_RAPTOR2_LIBRARY_DIRS:
statusPC_RAPTOR2_INCLUDEDIR: /usr/include/raptor2
statusPC_RAPTOR2_INCLUDE_DIRS: /usr/include/raptor2

It seems okay to me, thus I am now even more lost.. :)

Best Regards,
Laszlo Papp
--

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] Multiple source directory scenario and cdt generator

[Dan Kegel]

On Mon, Nov 14, 2011 at 3:37 PM, Dan Kegel  wrote:
> On Sat, Nov 12, 2011 at 11:04 AM, Alexander Neundorf
>  wrote:
>> * please give current cmake master a try, it has several improvements.
>
> I'll give cmake master a spin sometime this week.

Tried it.  It seems to get the linking right, though I'm not
sure how excited my users are going to be about how
deeply buried those source files are in the GUI.  There's
a whole lot of visual cruft around them.

I may stick with a hybrid approach: use the links you generate now,
but also generate my own phony .projects.  That way the source
files show up uncluttered at the top level, but the dependencies
now work thanks to your new links.
- Dan
--

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] Multiple source directory scenario and cdt generator

[Dan Kegel]

On Tue, Nov 15, 2011 at 1:28 PM, Dan Kegel  wrote:
> Tried it.  It seems to get the linking right, though I'm not
> sure how excited my users are going to be about how
> deeply buried those source files are in the GUI.  There's
> a whole lot of visual cruft around them.

Worse, the Team menu is inactive for these files.

I suspect that the only way to make source code control
plugins happy is to link to dummy projects like you
do for the main source directory.
And then there's no need for those individual source file links.
- Dan
--

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

[Stefan Monnier]

>> I'd still like to know how to explain to cmake that the command produces
>> 2 files, but at least I can get rid of my hack.
> That (assuming just a simple object file is produced by compilation)
> is one of several general limitations with CMake language support. For
> example, my understanding is this issue has been taken care of for
> Fortran 95 (where compilation produces both object and module files)
> with Fortran-95 specific changes to the C++ cmake code.  But I would far
> prefer to see a generic mechanism for this to not only to deal with
> the Fortran 95 module issue, but also the compilation-generated Ada
> library identification (*.ali) files, and also the similar issue for
> OCaml compiler generated files that you have described.

Hmm...

> Because of this and other struggles I had trying to implement Ada
> language support for CMake, I didn't even consider implementing CMake
> language support for OCaml for the PLplot OCaml bindings.  Instead we
> currently use (many!) custom commands and targets for that case, but
> I would be happy to change to your CMake OCaml language support
> if/when that works.

I'm trying to use CMake for a new project here.  This project (a new
programming language, whose first implementation is in OCaml) is
currently in the very first stages (I have barely more than the lexer
written) and doesn't require anything sophisticated (there's only
1 OCaml file for now ;-).  So my "language support" is very primitive
and rather than fight CMake, I'll probably just switch to something
else :-(


Stefan

--

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

[Bill Hoffman]

On 11/14/2011 3:24 PM, Alan W. Irwin wrote:



If you are willing to make such an OCaml summary, I would be willing
to do the same thing for Ada to make our joint case to the CMake
developers of what kind of additional generic language support is
needed by CMake to deal with the complicated build needs of languages
such as OCaml and Ada (and Fortran 95) in a completely generic way.



There is no case to make, I would love to improve the general language 
support.  However, either you find someone to develop this for you, or 
you find someone willing to pay someone to develop it.  That is really 
how open source works.  Creating a generic way to add new languages 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.


The custom commands are the best way to do this in CMake today, and 
likely in the near future.  Basically, they can be used to do just about 
anything ( I have seen latex, and all sorts of other things done with 
custom commands.)


-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] Adding a new language

[Bill Hoffman]

On 11/15/2011 10:13 PM, Stefan Monnier wrote:



I'm trying to use CMake for a new project here.  This project (a new
programming language, whose first implementation is in OCaml) is
currently in the very first stages (I have barely more than the lexer
written) and doesn't require anything sophisticated (there's only
1 OCaml file for now ;-).  So my "language support" is very primitive
and rather than fight CMake, I'll probably just switch to something
else :-(


You should be able to use custom commands to what you need in CMake.  It 
really should not be that hard.  You create custom targets for the 
libraries of your language.  You then have custom commands that produce 
the outputs that make up the input to the custom targets.  So, I don't 
think you would need to fight CMake that much.  Just take a different 
approach.


-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] Adding a new language

[Alan W. Irwin]

On 2011-11-15 22:13-0500 Stefan Monnier wrote:


I'd still like to know how to explain to cmake that the command produces
2 files, but at least I can get rid of my hack.

That (assuming just a simple object file is produced by compilation)
is one of several general limitations with CMake language support. For
example, my understanding is this issue has been taken care of for
Fortran 95 (where compilation produces both object and module files)
with Fortran-95 specific changes to the C++ cmake code.  But I would far
prefer to see a generic mechanism for this to not only to deal with
the Fortran 95 module issue, but also the compilation-generated Ada
library identification (*.ali) files, and also the similar issue for
OCaml compiler generated files that you have described.


Hmm...


Because of this and other struggles I had trying to implement Ada
language support for CMake, I didn't even consider implementing CMake
language support for OCaml for the PLplot OCaml bindings.  Instead we
currently use (many!) custom commands and targets for that case, but
I would be happy to change to your CMake OCaml language support
if/when that works.


I'm trying to use CMake for a new project here.  This project (a new
programming language, whose first implementation is in OCaml) is
currently in the very first stages (I have barely more than the lexer
written) and doesn't require anything sophisticated (there's only
1 OCaml file for now ;-).  So my "language support" is very primitive
and rather than fight CMake, I'll probably just switch to something
else :-(


Hi Stefan:

I am sorry that CMake support for new languages with complicated needs
is not there yet, and I completely understand why you don't want to
get involved with that general problem for your limited OCaml needs.

However, I wouldn't give up on CMake entirely because of that
constraint.  Instead, I would suggest you use the alternative of
low-level CMake custom commands and custom targets to build what you
need to build with OCaml. For a detailed example of that approach, see
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/ocaml.cmake?view=log
(which sets things up for the OCaml parts of the PLplot build) ,
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/bindings/ocaml/CMakeLists.txt?view=log
(which gives examples of relevant custom commands and targets to build
the PLplot OCaml bindings), and
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/examples/ocaml/CMakeLists.txt?view=log
(which shows how we build the PLplot OCaml examples).

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
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Failure to generate correct output name in visual studio

[J Decker]

(Visual studio bug actually - as I was trying to find the actual
difference in the output, and finding none, I have to assume that
somehow visual studio is causing the addtion of .dll on a project
without a '.' in it )

Using visual studio 2010 as a generator...

The following fails to find the library output, which should be
'something'  but gets generated as 'something.dll' and 'something.lib'
in the project properties it shows linker output as
$(OutDir)$(TargetName)$(TargetExt)


ADD_LIBRARY( something SHARED sourcs.c )

SET_TARGET_PROPERTIES(${PROJECT_NAME} PROPERTIES
  SUFFIX ""
  PREFIX ""
)

install( TARGETS something
RUNTIME DESTINATION bin/\${CMAKE_INSTALL_CONFIG_NAME}
LIBRARY DESTINATION bin/\${CMAKE_INSTALL_CONFIG_NAME}
ARCHIVE DESTINATION lib/\${CMAKE_INSTALL_CONFIG_NAME} )



This is fixed if there is a dot in the name.

ADD_LIBRARY( something.module SHARED sourcs.c )
.
--

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] Issues with finding raptor in the soprano build

[Andreas Pakulat]

On 15.11.11 21:30:45, Laszlo Papp wrote:
> I have tried to grab more debug outputs, and here are my relevant printouts:
> 
> statusPC_RAPTOR2_LIBDIR: /usr/lib
> statusPC_RAPTOR2_LIBRARY_DIRS:
> statusPC_RAPTOR2_INCLUDEDIR: /usr/include/raptor2
> statusPC_RAPTOR2_INCLUDE_DIRS: /usr/include/raptor2
> 
> It seems okay to me, thus I am now even more lost.. :)

The interesting part is wether RAPTOR_LIBRARIES and RAPTOR_INCLUDE_DIR
are set properly. If not then the find_library and find_path commands
are not finding your lib and header. You could try with cmake --trace
and cmake --debug-output to get more detailed information from the
search fo the lib and header.

Another question is: What version does your installed raptor have and
what does soprano require in its CMake files?

Andreas

--

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] Issues with finding raptor in the soprano build

[Laszlo Papp]

-- RAPTOR_LIBRARIES: /usr/lib/libraptor2.so
-- RAPTOR_INCLUDE_DIR: /usr/include/raptor2

and

root@Kaname:/usr/src/packages/BUILD/Build# dpkg -S /usr/lib/libraptor2.so
libraptor2-dev: /usr/lib/libraptor2.so
root@Kaname:/usr/src/packages/BUILD/Build# dpkg -S /usr/include/raptor2/raptor.h
libraptor2-dev: /usr/include/raptor2/raptor.h
root@Kaname:/usr/src/packages/BUILD/Build# dpkg -s libraptor2-dev | grep Version
Version: 2.0.4-1
root@Kaname:/usr/src/packages/BUILD/Build# grep find_package
../CMakeLists.txt | grep Raptor
  find_package(Raptor 2.0.4)
root@Kaname:/usr/src/packages/BUILD/Build#

Best Regards,
Laszlo Papp
--

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