Re: [CMake] Restrictions on where a binary can be put?

[Michael Hertling]

On 01/09/2011 09:47 PM, Nizar Khalifa Sallem wrote:
> At Sun, 09 Jan 2011 21:42:49 +0100,
> Michael Hertling wrote:
>>
>> On 01/09/2011 09:09 PM, Andreas Pakulat wrote:
>>> On 09.01.11 21:05:21, Andreas Pakulat wrote:
>>>> On 09.01.11 14:24:16, Michael Hertling wrote:
>>>>> On 01/09/2011 12:58 PM, Andreas Pakulat wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm having a bit of a problem here changing the runtime output directory
>>>>>> for a binary. Its an executable target named 'setup' and I'd like to put 
>>>>>> it
>>>>>> into the top-level directory. Unfortunately it always ends up in the bin/
>>>>>> directory, which is what CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to.
>>>>>>
>>>>>> I'm using
>>>>>> set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY 
>>>>>> ${CMAKE_BINARY_DIR} )
>>>>>> after creating the target currently, which should work as far as I can 
>>>>>> see
>>>>>> from the documentation. Are there maybe any restrictions on what the
>>>>>> directory may be or what targets can be put there?
>>>>>>
>>>>>> If not, any suggestions how to debug this? I can see that the build.make
>>>>>> does already have the rule setup for putting the binary into bin/, so it
>>>>>> must be going wrong somewhere in the generation stage, but a simple cmake
>>>>>> --trace doesn't show up anything suspicious. Is there a switch to follow
>>>>>> the steps that cmake does during makefile-generation?
>>>>>
>>>>> Could you provide a minimal but complete example?
>>>>
>>>> Ok, attached case produces the error. Apparently the problem is fetching
>>>> the LOCATION property from the target and setting the
>>>> RUNTIME_OUTPUT_DIRECTORY afterwards. Looks like a cmake bug to me, so
>>>> I'll file a report.
>>>
>>> Ooops, forgot the attachment :)
>>
>> Now, I can confirm the issue; indeed, the GET_TARGET_PROPERTY() on the
>> LOCATION apparently renders the following SET_TARGET_PROPERTY() on the
>> RUNTIME_OUTPUT_DIRECTORY ineffective. As I cannot see any reason for
>> this, I'd agree that it should be considered as a bug. Besides, my
>> example was pointless: A simple clash of an executable "main" with
>> a subdirectory of the same name in CMAKE_BINARY_DIR, sorry. :/
>>
>> Regards,
>>
>> Michael

> I don't really understand why you want to get the LOCATION from your
> target, anyway, the get_target_property works fine if you use
> set_target_properties before it. [...]

...but SET_TARGET_PROPERTIES() doesn't work fine if it's used after
GET_TARGET_PROPERTY(), even if both operate on different properties.

> [...] I am not sure that the
> CMAKE_RUNTIME_OUTPUT_DIRECTORY makes a property which is
> "gettable". [...]

Why should any property be not gettable? Some are not settable, like
the LOCATION, but that's not the point. The point is that getting a
property, i.e. a read operation, should not have an impact on any
subsequent command which does not use the former's results.

> [...] If you can better explain what do you want to do with the
> LOCATION of your target may be someone can help.

Regards,

Michael

@ Martin O'Brien: On my side, everything works as usual.
___
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] Restrictions on where a binary can be put?

[Michael Hertling]

On 01/09/2011 09:32 PM, Nizar Khalifa Sallem wrote:
> At Sun, 9 Jan 2011 21:09:37 +0100,
> Andreas Pakulat wrote:
>>
>> [1  ]
>> On 09.01.11 21:05:21, Andreas Pakulat wrote:
>>> On 09.01.11 14:24:16, Michael Hertling wrote:
>>>> On 01/09/2011 12:58 PM, Andreas Pakulat wrote:
>>>>> Hi,
>>>>>
>>>>> I'm having a bit of a problem here changing the runtime output directory
>>>>> for a binary. Its an executable target named 'setup' and I'd like to put 
>>>>> it
>>>>> into the top-level directory. Unfortunately it always ends up in the bin/
>>>>> directory, which is what CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to.
>>>>>
>>>>> I'm using
>>>>> set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY 
>>>>> ${CMAKE_BINARY_DIR} )
>>>>> after creating the target currently, which should work as far as I can see
>>>>> from the documentation. Are there maybe any restrictions on what the
>>>>> directory may be or what targets can be put there?
>>>>>
>>>>> If not, any suggestions how to debug this? I can see that the build.make
>>>>> does already have the rule setup for putting the binary into bin/, so it
>>>>> must be going wrong somewhere in the generation stage, but a simple cmake
>>>>> --trace doesn't show up anything suspicious. Is there a switch to follow
>>>>> the steps that cmake does during makefile-generation?
>>>>
>>>> Could you provide a minimal but complete example?
>>>
>>> Ok, attached case produces the error. Apparently the problem is fetching
>>> the LOCATION property from the target and setting the
>>> RUNTIME_OUTPUT_DIRECTORY afterwards. Looks like a cmake bug to me, so
>>> I'll file a report.
>>
>> Ooops, forgot the attachment :)
>>
>> Andreas
>>
>> -- 
>> You should emulate your heros, but don't carry it too far.  Especially
>> if they are dead.
>> [2 test_output_dir.tar.gz ]
>>
>> [3  ]
>> ___
>> 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
> Hi,
> 
> You I tested your CMakeLists.txt and this is no way a cmake bug but if
> you sent  a wrong CMakeLists.txt file.
> just remove this line get_target_property( _var foo LOCATION ) since
> your target name is also "foo".
> Tested without it and it works like a charm:

What's wrong with Andreas' CMakeLists.txt? He uses GET_TARGET_PROPERTY()
correctly - of course, on a target "foo". The point is why *reading* a
target property has an influence on subsequently *setting* a different
target property.

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] Restrictions on where a binary can be put?

[Michael Hertling]

On 01/09/2011 09:09 PM, Andreas Pakulat wrote:
> On 09.01.11 21:05:21, Andreas Pakulat wrote:
>> On 09.01.11 14:24:16, Michael Hertling wrote:
>>> On 01/09/2011 12:58 PM, Andreas Pakulat wrote:
>>>> Hi,
>>>>
>>>> I'm having a bit of a problem here changing the runtime output directory
>>>> for a binary. Its an executable target named 'setup' and I'd like to put it
>>>> into the top-level directory. Unfortunately it always ends up in the bin/
>>>> directory, which is what CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to.
>>>>
>>>> I'm using
>>>> set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY 
>>>> ${CMAKE_BINARY_DIR} )
>>>> after creating the target currently, which should work as far as I can see
>>>> from the documentation. Are there maybe any restrictions on what the
>>>> directory may be or what targets can be put there?
>>>>
>>>> If not, any suggestions how to debug this? I can see that the build.make
>>>> does already have the rule setup for putting the binary into bin/, so it
>>>> must be going wrong somewhere in the generation stage, but a simple cmake
>>>> --trace doesn't show up anything suspicious. Is there a switch to follow
>>>> the steps that cmake does during makefile-generation?
>>>
>>> Could you provide a minimal but complete example?
>>
>> Ok, attached case produces the error. Apparently the problem is fetching
>> the LOCATION property from the target and setting the
>> RUNTIME_OUTPUT_DIRECTORY afterwards. Looks like a cmake bug to me, so
>> I'll file a report.
> 
> Ooops, forgot the attachment :)

Now, I can confirm the issue; indeed, the GET_TARGET_PROPERTY() on the
LOCATION apparently renders the following SET_TARGET_PROPERTY() on the
RUNTIME_OUTPUT_DIRECTORY ineffective. As I cannot see any reason for
this, I'd agree that it should be considered as a bug. Besides, my
example was pointless: A simple clash of an executable "main" with
a subdirectory of the same name in CMAKE_BINARY_DIR, sorry. :/

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] Restrictions on where a binary can be put?

[Michael Hertling]

On 01/09/2011 12:58 PM, Andreas Pakulat wrote:
> Hi,
> 
> I'm having a bit of a problem here changing the runtime output directory
> for a binary. Its an executable target named 'setup' and I'd like to put it
> into the top-level directory. Unfortunately it always ends up in the bin/
> directory, which is what CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to.
> 
> I'm using
> set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY 
> ${CMAKE_BINARY_DIR} )
> after creating the target currently, which should work as far as I can see
> from the documentation. Are there maybe any restrictions on what the
> directory may be or what targets can be put there?
> 
> If not, any suggestions how to debug this? I can see that the build.make
> does already have the rule setup for putting the binary into bin/, so it
> must be going wrong somewhere in the generation stage, but a simple cmake
> --trace doesn't show up anything suspicious. Is there a switch to follow
> the steps that cmake does during makefile-generation?

Could you provide a minimal but complete example? Currently, I can't
confirm this issue, i.e. the RUNTIME_OUTPUT_DIRECTORY property seems
to take precedence over the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable.
Nevertheless, if RUNTIME_OUTPUT_DIRECTORY is set to CMAKE_BINARY_DIR
from within a subdirectory, i.e. CMAKE_CURRENT_BINARY_DIR isn't equal
to CMAKE_BINARY_DIR, I can see quite strange things happening:

# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(ROD C)
ADD_SUBDIRECTORY(main)

# main/CMakeLists.txt:
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/main.c
"int main(void){return 0;}\n"
)
ADD_EXECUTABLE(main ${CMAKE_CURRENT_BINARY_DIR}/main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}
)

After CMaking from within an empty directory, building fails with:

.../gcc CMakeFiles/main.dir/main.c.o -o . -rdynamic
.../ld: cannot open output file .: Is a directory

If the RUNTIME_OUTPUT_DIRECTORY property is set to CMAKE_BINARY_DIR/bin,
e.g., everything works as expected, i.e. the executable gets written to
CMAKE_BINARY_DIR/bin. Also, no such problem occurs from within the top-
level directory, i.e. CMAKE_CURRENT_BINARY_DIR == CMAKE_BINARY_DIR.
Perhaps, these two phenomena are related?

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] control order of custom target as a sub-part of a customized KDE build

[Michael Hertling]

On 01/04/2011 09:16 PM, Shawn Rutledge wrote:
> I am building a KDE control panel plugin, and there is a requirement
> to use a different translation mechanism rather than the default Qt
> "tr" macros.  So I want to post-process my ui_*.h files to replace
> lines like this
> 
> ClearSiteDataDialog->setWindowTitle(tr2i18n("foo", 0));
> 
>  with the replacement code like this
> 
> 
> ClearSiteDataDialog->setWindowTitle(Translator::instance().lookupString(CSD_DIALOG_TITLE));
> 
> I wrote a python script to do that, and I'm calling it like this from
> cmakelists.txt:
> 
> cmake_minimum_required (VERSION 2.6.0)
> set (CMAKE_VERBOSE_MAKEFILE true)
> find_package(KDE4 REQUIRED)
> file(GLOB SRC_FILES *.cpp)
> set(kcm_my_plugin_PART_SRCS ${SRC_FILES})
> message(STATUS "build type ${CMAKE_BUILD_TYPE}")
> file(GLOB UI_FILES *.ui)
> message(STATUS "ui files ${UI_FILES}")
> kde4_add_ui_files(kcm_my_plugin_PART_SRCS ${UI_FILES})
> kde4_add_plugin(kcm_my_plugin ${kcm_my_plugin_PART_SRCS}
> ${LINUX_COMMON_SOURCE} ${COMMON_SOURCE} ${COMMON_SOURCE_IMPL})
> target_link_libraries(kcm_my_plugin  ${KDE4_KDEUI_LIBS}
> ${KDE4_KCMUTILS_LIBS} ${X11_LIBRARIES} kutils)
> # post-process the ui_*.h header files AFTER they have been generated
> but BEFORE compiling anything
> add_custom_target(ui_translate
>   COMMAND ${CMAKE_SOURCE_DIR}/tools/convert-tr2-all.py
>   WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
> ADD_DEPENDENCIES(kcm_my_plugin ui_translate)
> ADD_DEPENDENCIES(kcm_my_plugin_automoc ui_translate)
> 
> 
> The only trouble is, it tries to call the script at the beginning of
> the build process, so the first time I run "make" it fails, and the
> second time after the ui_*.h files have been generated it succeeds.
> So, I need to control the order somehow, and I haven't dug deep enough
> into the KDE4 package to understand how the existing steps are done in
> the right order.  I need to append my extra step after the point where
> it generates the ui header files from the UI files.  I'm looking for
> ideas on what the dependency should be - which target do I depend on
> to get it done at the right time?

AFAICS, you need a dependency of ui_translate on the ui_*.h files:

add_custom_target(ui_translate
COMMAND ${CMAKE_SOURCE_DIR}/tools/convert-tr2-all.py
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
DEPENDS ${kcm_my_plugin_PART_SRCS})
^^
Note that this only works within the same directory, i.e.
kde4_add_ui_files() and add_custom_target() must be
mentioned in the same CMakeLists.txt.

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] Installing Python Modules with CMake

[Michael Hertling]

On 01/04/2011 08:50 AM, Michael Wild wrote:
> On 01/03/2011 06:23 PM, Todd Gamblin wrote:
>> On Jan 3, 2011, at 1:34 AM, Michael Wild wrote:
>>
>>> On 01/03/2011 09:11 AM, Todd Gamblin wrote:
 Is there some standard way in CMake to get a project-local install 
 destination for python libraries, e.g.:

${CMAKE_INSTALL_PREFIX}/lib/python2.6/site-packages

 Is this something find modules typically provide?  I can construct this 
 name easily enough myself, but it involves querying the python executable 
 for its version then regexing that string, and I feel like FindPythonLibs 
 should do stuff like that for me.  It would be nice to have something 
 called, say, "CMAKE_PYTHON_INSTALL_PREFIX" set to this path in advance, so 
 that I can just install python modules there.

 Or am I missing something?  I couldn't fund much on installing python 
 files in the docs.

 -Todd

>>>
>>> I think you'll have to query Python yourself. Of course, this becomes
>>> difficult if you're cross-compiling, in which case you would need to
>>> parse the /lib/pythonX.Y/config/Makefile file yourself and fetch
>>> all the relevant variables (datarootdir, BINDIR, DESTSHARED, LIBDEST,
>>> etc.) and then ask the user what prefix and exec_prefix he wants
>>> (presumably CMAKE_INSTALL_PREFIX maps to prefix, and usually exec_prefix
>>> is the same as prefix, but that's not always the case). Not sure how
>>> that works on Windows, though...
>>
>> That's kind of difficult because if I have just 'python', I don't have the 
>> version yet, so how am I supposed to find the Makefile?
>>
>> Off the top of my head, the most portable way to do this would be to find 
>> the python-config (which you can get by appending -config to the exe path, 
>> even if it's just python and not pythonX.Y) and then:
>>
>>  head -1 `which ${PYTHON_CONFIG}` | sed 's/.*\([0-9].[0-9]\)$/\1/'
>>
>> Or the equivalent in CMake using string(REGEXP ...).
>>
>> That will get you the version without running anything, and then you can go 
>> and find the Makefile.
> 
> 
> That only works on *NIX, on Windows there's AFAIK no python-config. So
> if you plan to cross-compile for Windows you might run into trouble.
> Probably it's best to not try being über-smart, and just leave it to the
> user to provide the information.
> 
> 
>> In the non cross-compiled case, though, it would be nice to just have a 
>> module that gives you all the information from python-config.
> 
> Better run
> 
> ${PYTHON_EXECUTABLE} -c "import sys; sys.stdout.write(sys.prefix+'\n')"
> 
> and similar, which also works on WIN32.
> 
>>
>> -Todd
>>
>>
>>> I wouldn't rely too much on FindPythonLibs. The whole FindPython* is a
>>> sorry mess (IMHO) and needs some serious overhaul, but that is some
>>> major undertaking an apparently the suffering wasn't big enough so far
>>> for somebody to take action...
>>
>> I noticed you guys had a long discussion about finding Python 3.  Did you 
>> come to any conclusions on this?  It would be nice to have a python 
>> detection Find module that works if you *just* give it your python 
>> executable.  I don't mind writing something like this up if no one else is 
>> up for it, but if I'm going to write it I'd like to make something that 
>> people will use.
>>
>> Thoughts?
>>
> 
> AFAIK, the issue hasn't been resolved. One of the big problems IMHO is,
> that FindPythonInterp and FindPythonLibs can report different python
> installations. Also, what should happen if the user manually changes the
> cache entry for the interpreter, but doesn't update the libraries? Also,
> some users of the module will just want the "most recent version" of
> Python, while others will specifically want the most recent 2.x version
> because their code isn't ready for python3. If
> you can come up with something that works well on all important
> platforms and is reasonably backwards compatible, you probably would
> make a lot of people happy ;-)
> 
> Michael

On Todd's request for commentary. Please note that the following
remarks are merely my personal opinion; of course, one can take
different positions:

A major obstacle for the development of smart/robust/comprehensive
find modules is the current incapability of the four find functions
FIND_{PATH,FILE,PROGRAM,LIBRARY}() to process filename patterns, e.g.
FIND_PROGRAM(PYTHON_EXECUTABLE PATTERN python*.* ...) or regex'd with
FIND_PROGRAM(PYTHON_EXECUTABLE PATTERN python[0-9]+\.[0-9]+ ...). All
these functions are able to look in any corner of the system, but they
search for fixed filenames only, especially resulting in problems like
the one reported with versioned Python directories. Furthermore, this
limitation constrains the authors of several find modules to hard-code
versions, e.g. Find{Python{Interp,Libs},TCL,PNG,Boost}.cmake, bearing
the need for continuous maintenance on the developers' as well as the
users' side. Additionally, issues like 10718 occasionally 

Re: [CMake] How to find the path to the currently include() or find_package file()

[Michael Hertling]

On 01/04/2011 07:41 AM, Michael Hertling wrote:
> On 01/04/2011 05:47 AM, John McGehee wrote:
>> I am using CMake 2.8 on Linux and Windows.
>>
>> When I include() or find_package() a .cmake file, is there a variable that I 
>> can use within the included .cmake file that will tell me its path?
>>
>> For example,
>>
>>   # In CMakeLists.txt
>>   include(somePath/foo.cmake)
>>
>> Within somePath/foo.cmake, I want to include bar.cmake which is in the same 
>> directory as foo.cmake,
>>
>>   # In somePath/foo.cmake
>>   include(${CMAKE_VARIABLE_THAT_IS_THE_ANSWER_TO_THIS_QUESTION}/bar.cmake)
>>
>> where ${CMAKE_VARIABLE_THAT_IS_THE_ANSWER_TO_THIS_QUESTION} = "somePath", 
>> the path to foo.cmake, which is currently being evaluated.
> 
> Use CMAKE_CURRENT_LIST_FILE in conjunction with GET_FILENAME_COMPONENT():

Oops...or just CMAKE_CURRENT_LIST_DIR. ;|

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] How to find the path to the currently include() or find_package file()

[Michael Hertling]

On 01/04/2011 05:47 AM, John McGehee wrote:
> I am using CMake 2.8 on Linux and Windows.
> 
> When I include() or find_package() a .cmake file, is there a variable that I 
> can use within the included .cmake file that will tell me its path?
> 
> For example,
> 
>   # In CMakeLists.txt
>   include(somePath/foo.cmake)
> 
> Within somePath/foo.cmake, I want to include bar.cmake which is in the same 
> directory as foo.cmake,
> 
>   # In somePath/foo.cmake
>   include(${CMAKE_VARIABLE_THAT_IS_THE_ANSWER_TO_THIS_QUESTION}/bar.cmake)
> 
> where ${CMAKE_VARIABLE_THAT_IS_THE_ANSWER_TO_THIS_QUESTION} = "somePath", the 
> path to foo.cmake, which is currently being evaluated.

Use CMAKE_CURRENT_LIST_FILE in conjunction with GET_FILENAME_COMPONENT():

# In somePath/foo.cmake
get_filename_component(somePath ${CMAKE_CURRENT_LIST_FILE} PATH)
include(${somePath}/bar.cmake)

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 uses wrong symlink to so

[Michael Hertling]

On 12/31/2010 03:43 PM, Michael Wild wrote:
> On 12/31/2010 02:48 PM, Michael Hertling wrote:
>> On 12/31/2010 11:56 AM, Michael Wild wrote:
>>> On 12/30/2010 07:55 PM, j s wrote:
>>>> Hello Michael Wild,
>>>>
>>>> I regret deciding to go with an Python parser for my application.  I use
>>>> such a small subset of the API, I was hoping to be able to rerelease my app
>>>> everytime it changes.
>>>>
>>>> Apparently Python 2.6 is frozen.
>>>>
>>>> In the future, the Python people are hoping to stabilize the ABI in the 3
>>>> series so that I can just link against a libpython3.so:
>>>> http://www.python.org/dev/peps/pep-0384/
>>>>
>>>> As stated by Michael Hertling, the symlinks are not being recursively
>>>> resolved.  The soname is encoded into the so, so the linker chooses to
>>>> ignore the original filename.
>>>>
>>>> Regards,
>>>>
>>>> Juan
>>>>
>>>> On Thu, Dec 30, 2010 at 6:23 AM, Michael Wild  wrote:
>>>>
>>>>> On 12/30/2010 12:28 AM, j s wrote:
>>>>>> I specified the full name to an so in CMAKE 2.8.1.  Unfortunately it
>>>>> links
>>>>>> against the versioned so name,
>>>>>> libpython2.6.so.1.0
>>>>>>
>>>>>> instead of the exact name I specified.
>>>>>> /usr/lib/libpython2.6.so
>>>>>>
>>>>>> SET (PYTHON_ARCHIVE /usr/lib/libpython2.6.so)
>>>>>> TARGET_LINK_LIBRARIES (myapp  parser engine ${PYTHON_ARCHIVE}
>>>>>> ${OPENSSL_ARCHIVE})
>>>>>>
>>>>>> Is there any way to tell cmake to do the right thing in Linux?  For some
>>>>>> strange reason using -l on the link line, and doesn't even use the
>>>>>> corresponding -L to the path I specify.
>>>>>>   -lpython2.6
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Juan
>>>>>
>>>>> There's nothing CMake can do about this, this is the linker getting in
>>>>> your way. E.g. on my Ubuntu, /usr/lib/libpython2.6.so is a symlink to
>>>>> /usr/lib/libpython2.6.so.1 which itself is a symlink to
>>>>> /usr/lib/libpython2.6.so.1.0. The linker recursively resolves all
>>>>> symlinks during the linking, and CMake can't do anything about it. You
>>>>> could pass the full path to the /usr/lib/libpython2.6.so symlink instead
>>>>> of -lpython2.6 and you would still get the same result.
>>>>>
>>>>> Actually, this is considered to be a feature. This way, newly compiled
>>>>> programs will always link against the "current" version (the one pointed
>>>>> to by the symlink-chain), while old programs can still use  older
>>>>> versions of the library without requiring to be recompiled.
>>>>>
>>>>> Michael
>>>
>>>
>>> Huh?
>>>
>>> $ echo "int main(){}" | gcc -x c -c -o test.o -
>>> $ gcc test.o /usr/lib/libpython2.6.so
>>> $ ldd a.out | grep libpython2.6
>>> libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0x7fbb350f1000)
>>>
>>> $ ls -l /usr/lib/libpython2.6.so*
>>> ... /usr/lib/libpython2.6.so -> libpython2.6.so.1
>>> ... /usr/lib/libpython2.6.so.1 -> libpython2.6.so.1.0
>>> ... /usr/lib/libpython2.6.so.1.0
>>>
>>> Sure looks like recursive symlink resolution to me...
>>
>> No, it's the soname that gets incorporated in the resulting binary;
>> recursively resolving the symlinks is insignificant in this regard:
>>
>> echo "void f(void){}" > f.c
>> echo "void g(void){}" > g.c
>> gcc -o libf.so -shared -fPIC -Wl,-soname,xyz f.c
>> gcc -o libg.so.1.0 -shared -fPIC g.c
>> ln -sf libg.so.1.0 libg.so.1
>> ln -sf libg.so.1 libg.so
>> ls -l libg.so*
>> ... libg.so -> libg.so.1
>> ... libg.so.1 -> libg.so.1.0
>> ... libg.so.1.0
>>
>> echo "int main(void){return 0;}" > main.c
>> gcc -o main main.c libf.so libg.so
>> LD_LIBRARY_PATH=. ldd main
>> ...
>> xyz => not found
>> libg.so => ./libg.so (0xb7fbd000)
>> ...
>>
>> A recursive symlink resolution would make the main executable being
>> linked against lib

Re: [CMake] CMAKE uses wrong symlink to so

[Michael Hertling]

On 12/31/2010 11:56 AM, Michael Wild wrote:
> On 12/30/2010 07:55 PM, j s wrote:
>> Hello Michael Wild,
>>
>> I regret deciding to go with an Python parser for my application.  I use
>> such a small subset of the API, I was hoping to be able to rerelease my app
>> everytime it changes.
>>
>> Apparently Python 2.6 is frozen.
>>
>> In the future, the Python people are hoping to stabilize the ABI in the 3
>> series so that I can just link against a libpython3.so:
>> http://www.python.org/dev/peps/pep-0384/
>>
>> As stated by Michael Hertling, the symlinks are not being recursively
>> resolved.  The soname is encoded into the so, so the linker chooses to
>> ignore the original filename.
>>
>> Regards,
>>
>> Juan
>>
>> On Thu, Dec 30, 2010 at 6:23 AM, Michael Wild  wrote:
>>
>>> On 12/30/2010 12:28 AM, j s wrote:
>>>> I specified the full name to an so in CMAKE 2.8.1.  Unfortunately it
>>> links
>>>> against the versioned so name,
>>>> libpython2.6.so.1.0
>>>>
>>>> instead of the exact name I specified.
>>>> /usr/lib/libpython2.6.so
>>>>
>>>> SET (PYTHON_ARCHIVE /usr/lib/libpython2.6.so)
>>>> TARGET_LINK_LIBRARIES (myapp  parser engine ${PYTHON_ARCHIVE}
>>>> ${OPENSSL_ARCHIVE})
>>>>
>>>> Is there any way to tell cmake to do the right thing in Linux?  For some
>>>> strange reason using -l on the link line, and doesn't even use the
>>>> corresponding -L to the path I specify.
>>>>   -lpython2.6
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Juan
>>>
>>> There's nothing CMake can do about this, this is the linker getting in
>>> your way. E.g. on my Ubuntu, /usr/lib/libpython2.6.so is a symlink to
>>> /usr/lib/libpython2.6.so.1 which itself is a symlink to
>>> /usr/lib/libpython2.6.so.1.0. The linker recursively resolves all
>>> symlinks during the linking, and CMake can't do anything about it. You
>>> could pass the full path to the /usr/lib/libpython2.6.so symlink instead
>>> of -lpython2.6 and you would still get the same result.
>>>
>>> Actually, this is considered to be a feature. This way, newly compiled
>>> programs will always link against the "current" version (the one pointed
>>> to by the symlink-chain), while old programs can still use  older
>>> versions of the library without requiring to be recompiled.
>>>
>>> Michael
> 
> 
> Huh?
> 
> $ echo "int main(){}" | gcc -x c -c -o test.o -
> $ gcc test.o /usr/lib/libpython2.6.so
> $ ldd a.out | grep libpython2.6
> libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0x7fbb350f1000)
> 
> $ ls -l /usr/lib/libpython2.6.so*
> ... /usr/lib/libpython2.6.so -> libpython2.6.so.1
> ... /usr/lib/libpython2.6.so.1 -> libpython2.6.so.1.0
> ... /usr/lib/libpython2.6.so.1.0
> 
> Sure looks like recursive symlink resolution to me...

No, it's the soname that gets incorporated in the resulting binary;
recursively resolving the symlinks is insignificant in this regard:

echo "void f(void){}" > f.c
echo "void g(void){}" > g.c
gcc -o libf.so -shared -fPIC -Wl,-soname,xyz f.c
gcc -o libg.so.1.0 -shared -fPIC g.c
ln -sf libg.so.1.0 libg.so.1
ln -sf libg.so.1 libg.so
ls -l libg.so*
... libg.so -> libg.so.1
... libg.so.1 -> libg.so.1.0
... libg.so.1.0

echo "int main(void){return 0;}" > main.c
gcc -o main main.c libf.so libg.so
LD_LIBRARY_PATH=. ldd main
...
xyz => not found
libg.so => ./libg.so (0xb7fbd000)
...

A recursive symlink resolution would make the main executable being
linked against libg.so.1.0 instead of libg.so. In fact, main is linked
against the library specified by the soname - if present - even if that
library doesn't exist at all like xyz in the example above. If there is
no soname the linker incorporates the library as denoted on the command
line. With libpython2.6, the executable is linked against .so.1.0 since
this is the library's soname, but not due to the .so-->so.1-->.so.1.0
symlink resolution. BTW, the soname denoting the non-existing xyz is
completely artificial, of course, and designed only to clarify the
concern. Usually, ldconfig ensures that there is a valid symlink
soname --> actual library file.

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] How to make a ProjectConfig.cmake

[Michael Hertling]

On 12/30/2010 06:59 PM, Ian Monroe wrote:
> On Thu, Dec 30, 2010 at 09:42, Michael Wild  wrote:
>> On 12/30/2010 03:34 PM, Ian Monroe wrote:
>>> On Thu, Dec 30, 2010 at 08:08, Michael Hertling  wrote:
>>>> On 12/30/2010 11:33 AM, Ian Monroe wrote:
>>>>> To create my QyotoConfig.cmake I need to know the full path of a
>>>>> library so that I can set a variable like QYOTO_LIBRARY.
>>>>>
>>>>> This is pretty standard requirement right? Its what we're supposed to
>>>>> do in *Config.cmake's?
>>>>
>>>> Yes.
>>>>
>>>>> So anyways, how do I that? The only target property that hasn't
>>>>> returned NOTFOUND is LOCATION, which unhelpfully returns the location
>>>>> of the library in the build directory. I could parse this to get the
>>>>> file name, and then append it to the library install location... but
>>>>> that seems like such a hack. Feels like I'm doing something wrong if I
>>>>> need to use a hack to do something standard.
>>>>
>>>> Usually, I'd have a template QyotoConfig.cmake.in which contains
>>>>
>>>> FIND_LIBRARY(QYOTO_LIBRARY qyoto
>>>>PATHS @CMAKE_INSTALL_PREFIX@/lib
>>>>NO_DEFAULT_PATH
>>>> )
>>>>
>>>> and is processed by CONFIGURE_FILE(). If the library is installed with
>>>>
>>>> INSTALL(TARGETS qyoto
>>>>RUNTIME DESTINATION bin
>>>>LIBRARY DESTINATION lib
>>>>ARCHIVE DESTINATION lib
>>>> )
>>>>
>>>> the FIND_LIBRARY() in the resulting QyotoConfig.cmake file will find
>>>> the library right at the installation location but nowhere else, and
>>>> the platform-dependent file names, e.g. libqyoto.so versus qyoto.dll,
>>>> are also handled correctly.
>>>>
>>>>> I looked at install(EXPORT which could work, but it seems to include a
>>>>> lot more information then is needed. I just want to set a variable
>>>>> with the full path to a library.
>>>>
>>>> Nevertheless, the imported-targets approach, i.e. the combination of
>>>> INSTALL(TARGETS ... EXPORT ...) and INSTALL(EXPORT ...) along with an
>>>> appropriately set up config file, is much more powerful and should be
>>>> preferred, IMO; see [1] for more information. BTW, as the export file
>>>> defines the imported targets, its inclusion in the config file should
>>>> possibly be protected in a suitable way to avoid fatal redefinitions.
>>>
>>> The context I'm coming from is that I'm developing stuff that is
>>> distributed by Linux distributions. The export file has information
>>> about what the target is dependent on, including full paths. That
>>> feels like a bad thing to me. What was true about dependencies when a
>>> package was being built on a build server might not be true later.
>>
>> If the paths on the build server don't match the ones on the destination
>> system, then that distro is broken. Period. Here's what happens in the
>> case of Debian/Ubuntu/...:
>>
>> - A minimal installation is unpacked from a tar-ball
>> - The system chroots into the unpacked system
>> - All dependencies are installed into the build environment
>> - The package is built
>> - The system exits the chroot, retrieves the package and discards the
>> build environment
>>
>> This is to guarantee that the dependencies are set up correctly and that
>> no strange interferences occur.
> 
> Yes, I know how build systems work. But if some library that I depends
> on changes where it is installed, that very well might not matter at
> all to running my application. And mostly certainly not to building
> it.
> 
> ...yet the EXPORT-created cmake would still refer to this old file.
> Maybe it doesn't really matter, just seems like bad practice to be
> referring to files that aren't yours in these cmake files that get
> installed.

This issue isn't limited to configuration files with imported targets
or their usage in a Linux distribution. Even with the, say, classical
approach, you have hardcoded paths of library/executable files or the
like in the config file, so the latter is valid for the system's state
at the very moment of the installation. When a package's prerequisites
are changed later the config file is in danger to be broken. That's a
fundamental difference to find modules which can search prerequisites
dynamically and return with _FOUND==FALSE as the case may be.
Anyway, I think we have to put up with this possible raw point, but a
well administrated system - or a well organized distribution - should
keep the risks small.

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] FLTKConfig.cmake on Microsoft Windows

[Michael Hertling]

On 12/30/2010 11:01 AM, Julia Jacobson wrote:
> With your help, everything seems to work now.
> My final subdirectory src/CMakeLists.txt looks like this:
> 
> SET(FLTK_DIR "C:/Program Files/fltk-1.1.9/")
> SET(FLTK_BASE_LIBRARY "C:/Program Files/fltk-1.1.9/lib/")
> SET(FLTK_FORMS_LIBRARY "C:/Program Files/fltk-1.1.9/lib/")
> SET(FLTK_GL_LIBRARY "C:/Program Files/fltk-1.1.9/lib/")
> SET(FLTK_IMAGES_LIBRARY "C:/Program Files/fltk-1.1.9/lib/")
> SET(FLTK_INCLUDE_DIR "C:/Program Files/fltk-1.1.9/include/")
> SET(FLTK_SKIP_FLUID TRUE)
> FIND_PACKAGE(FLTK REQUIRED)
> if( FLTK_FOUND )
> include_directories( ${FLTK_INCLUDE_DIR} )
> add_executable( hello main.cpp )
> target_link_libraries( hello ${FLTK_LIBRARIES} )
> else( FLTK_FOUND )
> message(FATAL_ERROR "Could not find FLTK")
> endif( FLTK_FOUND )
> 
> What grieves me is that the CMake code I had prepared in linux looked 
> really nice (without any absolute paths and so on), but the file for 
> Windows doesn't.
> Truth be told, what's the point of using CMake here instead of a 
> Makefile? Simply rewriting the build script doesn't cause that more work 
> either.
> Would it help to add the FLTK directory to the Windows PATH variable?

FYI: On *nix, I have installed FLTK 1.1.10 in /tmp/fltk for testing
purposes, and CMake gracefully finds it when CMAKE_PREFIX_PATH is set
accordingly, i.e. cmake -DCMAKE_PREFIX_PATH=/tmp/fltk ... IMO, that's
the preferred way to direct FIND_PACKAGE() to an exceptional location.
So, have you already tried this instead of setting FLTK_INCLUDE_DIR,
FLTK_DIR or the like?

Regards,

Michael

>> Am Mittwoch, den 29.12.2010, 20:03 +0100 schrieb Julia Jacobson:
>>> Thanks for your answer. The file FindFLTK.cmake exists within my CMake
>>> installation, but I still get an error message:
>>> "CMake Error at C:/Program Files/CMake
>>> 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91
>>> (MESSAGE):
>>> Could NOT find FLTK (missing: FLTK_LIBRARIES FLTK_FLUID_EXECUTABLE)"
>>> This is probably due to the fact that I haven't indicated anywhere where
>>> to find my FLTK installation (i.e. C:\Program Files\fltk-1.1.10).
>>>
>> Actually the module file (here FindFLTK) should find the libraries on
>> any platforms, but in this case...
>>
>> Before FIND_PACKAGE(FLTK REQUIRED) insert:
>>
>> SET(FLTK_DIR "C:/Program Files/fltk-1.1.10") # NO backslash!
>>
>> If you did not install "fluid")
>> SET(FLTK_SKIP_FLUID TRUE)
>>
>> FIND_PACKAGE(...
>>
>> Micha
___
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 make a ProjectConfig.cmake

[Michael Hertling]

On 12/30/2010 11:33 AM, Ian Monroe wrote:
> To create my QyotoConfig.cmake I need to know the full path of a
> library so that I can set a variable like QYOTO_LIBRARY.
> 
> This is pretty standard requirement right? Its what we're supposed to
> do in *Config.cmake's?

Yes.

> So anyways, how do I that? The only target property that hasn't
> returned NOTFOUND is LOCATION, which unhelpfully returns the location
> of the library in the build directory. I could parse this to get the
> file name, and then append it to the library install location... but
> that seems like such a hack. Feels like I'm doing something wrong if I
> need to use a hack to do something standard.

Usually, I'd have a template QyotoConfig.cmake.in which contains

FIND_LIBRARY(QYOTO_LIBRARY qyoto
PATHS @CMAKE_INSTALL_PREFIX@/lib
NO_DEFAULT_PATH
)

and is processed by CONFIGURE_FILE(). If the library is installed with

INSTALL(TARGETS qyoto
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib
)

the FIND_LIBRARY() in the resulting QyotoConfig.cmake file will find
the library right at the installation location but nowhere else, and
the platform-dependent file names, e.g. libqyoto.so versus qyoto.dll,
are also handled correctly.

> I looked at install(EXPORT which could work, but it seems to include a
> lot more information then is needed. I just want to set a variable
> with the full path to a library.

Nevertheless, the imported-targets approach, i.e. the combination of
INSTALL(TARGETS ... EXPORT ...) and INSTALL(EXPORT ...) along with an
appropriately set up config file, is much more powerful and should be
preferred, IMO; see [1] for more information. BTW, as the export file
defines the imported targets, its inclusion in the config file should
possibly be protected in a suitable way to avoid fatal redefinitions.

Regards,

Michael

[1] http://www.cmake.org/Wiki/CMake_2.6_Notes#Packaging_and_Exporting
___
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 uses wrong symlink to so

[Michael Hertling]

On 12/30/2010 12:28 AM, j s wrote:
> I specified the full name to an so in CMAKE 2.8.1.  Unfortunately it links
> against the versioned so name,
> libpython2.6.so.1.0
> 
> instead of the exact name I specified.
> /usr/lib/libpython2.6.so
> 
> SET (PYTHON_ARCHIVE /usr/lib/libpython2.6.so)
> TARGET_LINK_LIBRARIES (myapp  parser engine ${PYTHON_ARCHIVE}
> ${OPENSSL_ARCHIVE})
> 
> Is there any way to tell cmake to do the right thing in Linux?  For some
> strange reason using -l on the link line, and doesn't even use the
> corresponding -L to the path I specify.
>   -lpython2.6

See [1] for an explanation of the latter behavior. Nevertheless, I
can confirm that - on my system - /usr/lib/libpython2.5.so turns to
-lpython2.5 whereas /usr/lib/libpython2.5.so.1{,.0} do not. Here, I
assume that CMake just uses the well-known extensions .so and .a when
deciding whether a file specification denotes a library in an implicit
system location, so /usr/lib/libpython2.5.so is identified as such one,
but /usr/lib/libpython2.5.so.1{,.0} are not. This results in full paths
in the linker's command line for the latters and a -l option without an
appropriate -L one for the former. Use the trick with imported targets
to force a full path for the /usr/lib/libpythonX.X.so library, too.

However, the fact that your target links against libpython2.6.so.1.0
instead of libpython2.6.so is no CMake issue, but relates to that
library's soname; try

readelf -d /usr/lib/libpython2.6.so | grep SONAME

and see ld's manpage, in particular:

"-soname=name
   When creating an ELF shared object, set the internal DT_SONAME field
   to the specified name.  When an executable is linked with a shared
   object which has a DT_SONAME field, then when the executable is run
   the dynamic linker will attempt to load the shared object specified
   by the DT_SONAME field rather than the using the file name given to
   the linker."

'hope that helps.

Regards,

Michael

> [1] http://www.cmake.org/Wiki/CMake_2.6_Notes#Linking_to_System_Libraries
___
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] proper setup to create file and have it installed

[Michael Hertling]

On 12/28/2010 09:10 AM, edA-qa mort-ora-y wrote:
> On 12/27/2010 09:51 PM, Michael Hertling wrote:
>> You might use the ALL option of ADD_CUSTOM_TARGET() to incorporate the
>> language target in CMake's "all" target which, in turn, is built as a
>> prerequisite of the "install" target. Alternatively, if the language
>> file should be installed only if the language target has been built
>> before, you might use the OPTIONAL flag of the INSTALL(FILES ...)
>> command to avoid the fatal error due to a missing file.
> 
> Thank you, that works.
> 
> Now, a related question. Is there some way to successively add files
> dependencies to an add_custom_target? I know that DEPENDS does this, but
> it'd be nice if I could create a "install-files" target and in various
> points in the file add the files which are needed as dependencies.
> Otherwise I will basically have a new target for every install line
> which installs a generated file.

AFAIK, the ADD_CUSTOM_TARGET() command isn't open in this sense, i.e.
you can't enhance the dependencies after the target has been defined.
So, you must actually use multiple targets or collect everything and
define the custom target at the end, e.g. with your language files:

UNSET(LANGUAGES)
...
LIST(APPEND LANGUAGES "English")
...
LIST(APPEND LANGUAGES "French")
...
LIST(APPEND LANGUAGES "German")
...
UNSET(LANGFILES)
FOREACH(i IN LISTS LANGUAGES)
SET(LANGFILE ${CMAKE_CURRENT_BINARY_DIR}/${i}.qm)
ADD_CUSTOM_COMMAND(OUTPUT ${LANGFILE} COMMAND ... DEPENDS ...)
LIST(APPEND LANGFILES ${LANGFILE})
ENDFOREACH()
ADD_CUSTOM_TARGET(languages ALL DEPENDS ${LANGFILES})
INSTALL(FILES ${LANGFILES} DESTINATION ...)

The tricky part is how to set up the custom command within the loop.

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] proper setup to create file and have it installed

[Michael Hertling]

On 12/27/2010 12:32 PM, edA-qa mort-ora-y wrote:
> I'm using lupdate/lrelease in QT and trying to have a generated file
> installed. I've hit a few problems that I'm not clear on how they should
> be resolved.
> 
> To produce the file I have a chain of commands that ends with:
> 
> add_custom_command(
>   OUTPUT English.qm
>   COMMAND lrelease ${LANG_DIR}/MasterTypes.ts -qm English.qm
>   DEPENDS ${LANG_DIR}/MasterTypes.ts
>   )
> 
> To directly produce this file I add the following target:
> 
> add_custom_target( language
>   DEPENDS English.qm )
> 
> Now "make language" produces the file(s) as I want. I now however need
> to install them.  install files won't take a relative path so I've
> specified the following:
> 
> install( FILES ${CMAKE_BINARY_DIR}/src/gui/English.qm DESTINATION data/ )
> 
> I thought there might be some way to refer to the relative "English.qm"
> file. Is there?

INSTALL(FILES ...) does take relative paths, but they're interpreted
w.r.t. to the current source directory. Regarding files generated at
build time in the binary directories, one should use absolute paths
right from the beginning, e.g.:

add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/English.qm
COMMAND lrelease ${LANG_DIR}/MasterTypes.ts
-qm ${CMAKE_CURRENT_BINARY_DIR}/English.qm
DEPENDS ${LANG_DIR}/MasterTypes.ts
)
...
add_custom_target( language
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/English.qm )

> That aside, I need that the install command checks the dependencies on
> the file. As specified it does not, and I don't see a DEPENDS clause for
> install.  How do I ensure that the installation updates the file as
> required?

You might use the ALL option of ADD_CUSTOM_TARGET() to incorporate the
language target in CMake's "all" target which, in turn, is built as a
prerequisite of the "install" target. Alternatively, if the language
file should be installed only if the language target has been built
before, you might use the OPTIONAL flag of the INSTALL(FILES ...)
command to avoid the fatal error due to a missing file.

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 building libraries with no sources with Visual Studio 9 (2008)

[Michael Hertling]

On 12/22/2010 07:49 PM, Pere Mato Vila wrote:
>   AFAICS there are three different issues here:
> 
>  - Having a .def file as a source in a ADD_LIBRARY() it does the correct 
> thing, which is using it to build the library, but it does not create a 
> dependency to it. I would call this a bug.

For the nmake generator, this was asked in [1] two years ago but hasn't
received an answer; nevertheless, it seems to have been fixed recently
in [2]. However, I have no idea if it will work with the Visual Studio
generators and, as the case may be, why not. Perhaps due to the same
reason the upcoming LINK_DEPENDS property is limited to Makefiles?

> - The way to generate the .def file that I have figured out is perhaps not 
> optimal and Bill Hoffman has provided me with a solution that exploits 
> PRE_LINK option in  ADD_CUSTOM_COMMAND().

If I understand correctly, you need a dependency of ${library}.def on
${library}-static, and such a dependency can't be established by the
ADD_CUSTOM_COMMAND(TARGET ...) signature. In other words: A changed
${library}-static doesn't invalidate ${library}.def, so ${library}
isn't rebuilt despite the new dependency on .def files. See the
following example with an object file instead of a .def file:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(OBJECT C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
FILE(WRITE ${CMAKE_BINARY_DIR}/f0.c "void f0(void){}\n")
EXECUTE_PROCESS(COMMAND cc -c f0.c)
ADD_LIBRARY(f SHARED f.c f0.o)
ADD_CUSTOM_COMMAND(TARGET f PRE_LINK COMMAND cc -c f0.c)

f0.o is compiled right before the library target is linked, but
touching f0.c - the prerequisite of f0.o - will entail nothing.

> - If I use ADD_LBRARY() with no real source files and only with a .def file 
> does fail within the IDE (Visual Studio 9) and does work with nmake.

Just a spontaneous notion: On *nix, one can say

ADD_LIBRARY(f SHARED "" f.def)  # Note the "".
SET_TARGET_PROPERTIES(f PROPERTIES LINKER_LANGUAGE C)

In spite of f.def not being compilable such that there's no mediate
f.def <-- f dependency - that is what I actually meant with "CMake
does not know how to handle a .def file" - the target gets happily
built without object files, but I don't know if the Visual Studio
tools can be duped in this way.

Regards,

Michael

[1] http://www.mail-archive.com/cmake@cmake.org/msg17981.html
[2] http://public.kitware.com/Bug/view.php?id=11014

> On Dec 22, 2010, at 12:09 AM, Michael Hertling wrote:
> 
>> On 12/21/2010 08:45 PM, Bill Hoffman wrote:
>>> On 12/21/2010 2:17 PM, Michael Hertling wrote:
>>>
>>>> AFAIK, this is because CMake does not know how to handle a .def file
>>>> for incorporation in the target, i.e. ${library}.def has no LANGUAGE
>>>
>>> Actually, it should...
>>>
>>>
>>> Something like this should work:
>>> (assumes you have a perl script to create a .def file)
>>>
>>> cmake_minimum_required (VERSION 2.6)
>>> project (myexe)
>>>
>>> set (SOURCES mylib.cxx mylib2.cxx)
>>>
>>> # create a list of all the object files
>>> string (REGEX REPLACE "\\.cxx" ".obj" OBJECTS "${SOURCES}")
>>>
>>> # create a shared library with the .def file
>>> add_library (mylib SHARED ${SOURCES}
>>>   ${CMAKE_CURRENT_BINARY_DIR}/mylib.def
>>>   )
>>> # set the .def file as generated
>>> set_source_files_properties (
>>>   ${CMAKE_CURRENT_BINARY_DIR}/mylib.def
>>>   PROPERTIES GENERATED 1
>>>   )
>>>
>>> # create an executable
>>> add_executable (myexe myexe.cxx)
>>>
>>> # link the executable to the dll
>>> target_link_libraries(myexe mylib)
>>>
>>> #convert to windows slashes
>>> set (OUTDIR
>>>   ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}
>>>   )
>>>
>>> string (REGEX REPLACE "/" "" OUTDIR ${OUTDIR})
>>>
>>> # create a custom pre link command that runs
>>> # a perl script to create a .def file using dumpbin
>>> add_custom_command (
>>>   TARGET mylib PRE_LINK
>>>   COMMAND perl
>>>   ARGS ${CMAKE_CURRENT_SOURCE_DIR}/makedef.pl
>>>   ${CMAKE_CURRENT_BINARY_DIR}\\mylib.def mylib
>>>   ${OUTDIR} ${OBJECTS} )
>>
>> Sorry, I haven't expressed myself precisely. My point is that mentioning
>> the .def file in the target's sources does not establish a dependency of
>> the target on the .def file, so the target isn't rebuilt when the .def
>> file has changed:
>>
>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ER

Re: [CMake] Problem building libraries with no sources with Visual Studio 9 (2008)

[Michael Hertling]

On 12/21/2010 08:45 PM, Bill Hoffman wrote:
> On 12/21/2010 2:17 PM, Michael Hertling wrote:
> 
>> AFAIK, this is because CMake does not know how to handle a .def file
>> for incorporation in the target, i.e. ${library}.def has no LANGUAGE
> 
> Actually, it should...
> 
> 
> Something like this should work:
> (assumes you have a perl script to create a .def file)
> 
> cmake_minimum_required (VERSION 2.6)
> project (myexe)
> 
> set (SOURCES mylib.cxx mylib2.cxx)
> 
> # create a list of all the object files
> string (REGEX REPLACE "\\.cxx" ".obj" OBJECTS "${SOURCES}")
> 
> # create a shared library with the .def file
> add_library (mylib SHARED ${SOURCES}
>${CMAKE_CURRENT_BINARY_DIR}/mylib.def
>)
> # set the .def file as generated
> set_source_files_properties (
>${CMAKE_CURRENT_BINARY_DIR}/mylib.def
>PROPERTIES GENERATED 1
>)
> 
> # create an executable
> add_executable (myexe myexe.cxx)
> 
> # link the executable to the dll
> target_link_libraries(myexe mylib)
> 
> #convert to windows slashes
> set (OUTDIR
>${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}
>)
> 
> string (REGEX REPLACE "/" "" OUTDIR ${OUTDIR})
> 
> # create a custom pre link command that runs
> # a perl script to create a .def file using dumpbin
> add_custom_command (
>TARGET mylib PRE_LINK
>COMMAND perl
>ARGS ${CMAKE_CURRENT_SOURCE_DIR}/makedef.pl
>${CMAKE_CURRENT_BINARY_DIR}\\mylib.def mylib
>${OUTDIR} ${OBJECTS} )

Sorry, I haven't expressed myself precisely. My point is that mentioning
the .def file in the target's sources does not establish a dependency of
the target on the .def file, so the target isn't rebuilt when the .def
file has changed:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(DEFS C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
FILE(WRITE ${CMAKE_BINARY_DIR}/f.def.in "")
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_BINARY_DIR}/f1.def
COMMAND ${CMAKE_COMMAND} -E
copy ${CMAKE_BINARY_DIR}/f.def.in ${CMAKE_BINARY_DIR}/f1.def
DEPENDS ${CMAKE_BINARY_DIR}/f.def.in
)
SET_SOURCE_FILES_PROPERTIES(
${CMAKE_BINARY_DIR}/f2.def PROPERTIES GENERATED TRUE
)
ADD_LIBRARY(f SHARED f.c f1.def f2.def)
ADD_CUSTOM_COMMAND(
TARGET f
PRE_LINK
COMMAND ${CMAKE_COMMAND} -E copy
${CMAKE_BINARY_DIR}/f.def.in ${CMAKE_BINARY_DIR}/f2.def
)

Touching f1.def or f2.def does not make the target rebuild, and touching
f.def.in just makes f1.def regenerate. It's touching f.c that results in
rebuilding the target due to the f.c <-- f.c.o <-- libf.so dependencies.
AFAIK, such a dependency does not exist between the target and the .def
files, or have I got you wrong?

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 building libraries with no sources with Visual Studio 9 (2008)

[Michael Hertling]

On 12/21/2010 04:13 PM, Pere Mato Vila wrote:
> Dear all,
> 
>   I am trying to build shared libraries on Windows exporting all symbols. 
> This is as an alternative of instrumenting the code with dllimport/dllexport 
> declarations. For this I do build first a static library from which I get all 
> the defined symbols to write a .DEF file which is then used to build the 
> shared library. The CMake code (using version 2.8.3)  looks like this:
> 
> add_library( ${library}-static STATIC ${sources} ) 
> add_custom_command( OUTPUT {library}.def COMMAND  
> DEPENDS ${library}-static )
> add_library(${library} SHARED ${library}.def)
> target_link_libraries(${library}  ${library}-static ${other-libs} )
> set_target_properties(${library} PROPERTIES LINK_INTERFACE_LIBRARIES 
> ${other-libs})
> 
>This works just fine when using the nmake generator. The library is 
> created and has all the symbols are exported as desired. But, when using 
> Visual C++ 2008 express edition I get the following error message:
> 
> 1>.\mylib.dir\Debug\mylib.dll.intermediate.manifest : general error c1010070: 
> Failed to load and parse the manifest. The system cannot find the file 
> specified.
> 
>   The problem is that the shared library has been defined without any 'real' 
> source file (only the .def file is declared) and somehow the generated code 
> does not produce the required manifest file. Does anybody see a problem with 
> these kind of constructs?  Should it just work from within the IDE? 
>   Experimentally I have found a workaround, which consists in adding a dummy 
> source file in the shared library definition. 
> 
> ...
> file( WRITE ${library}.cpp "// empty file!!!\n" )
> add_library( ${library} SHARED ${library}.cpp ${library}.def)
> ... 
> 
> 
> I have also noticed that the dependency of the shared library to the .def 
> file is also missing. This is, newer versions of the .def file does not 
> trigger a re-build of the shared library. 

AFAIK, this is because CMake does not know how to handle a .def file
for incorporation in the target, i.e. ${library}.def has no LANGUAGE
property. Thus, its inclusion in the target's sources results in the
execution of the custom command only. Perhaps, you can enhance your
workaround with the dummy ${library}.cpp as follows:

ADD_CUSTOM_COMMAND(
OUTPUT {library}.def
COMMAND 
COMMAND ${CMAKE_COMMAND} -E touch ${library}.cpp
DEPENDS ${library}-static
)

This would invalidate ${library}.cpp each time ${library}.def is
regenerated, so the dummy is recompiled and ${library} relinked.

Regards,

Michael

PS: Don't write to the source directory with FILE(WRITE ...) or the like.
___
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] granular install advice

[Michael Hertling]

On 12/17/2010 03:31 PM, luxInteg wrote:
> Greetings,
> 
> I am learning cmake.
> 
> If I were to have  some  homebrewed "ModulesForCMakeIdiots.cmake" from my 
> learning project in say ${CMAKE_SOURCE_DIR}/modules
> and I set this command:-
> 
> install(FILES ${CMAKE_SOURCE_DIR}/modules/*.cmake /usr/local/someplace )
> 
> do be done  AT INSTALL time  
> (i.e. I want to  install the modules on  the file syatem say 
> /usr/local/someplace) -the above is like to   copy   the modules to 
> ${INSTALL_PREFIX}/usr/local/someplace.
> 
> So how do I  tell cmake to  copy to   /usr/local/someplace instead?

The correct signature of the INSTALL(FILES ...) command is

INSTALL(FILES ... DESTINATION /usr/local/someplace ...)
  ^^^
and the manual - which you've studied thoroughly, I suppose - states:

DESTINATION arguments specify the directory on disk to which a file
will be installed. If a *full path* (with a leading slash or drive
letter) is given it is used directly. If a relative path is given
it is interpreted relative to the value of CMAKE_INSTALL_PREFIX.

Besides, you can't specify the files for INSTALL(FILES ...) using the
'*' and other globbing characters as they are meaningful only for the
shell or specialized CMake commands like FILE(GLOB ...).

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] Dependency rule not included

[Michael Hertling]

On 12/08/2010 04:28 PM, Vivien Delmon wrote:
> On 12/08/2010 04:13 PM, Michael Wild wrote:
>> On 12/08/2010 03:54 PM, Micha Renner wrote:
>>> Am Mittwoch, den 08.12.2010, 14:55 +0100 schrieb Vivien Delmon:
 CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
 ADD_CUSTOM_COMMAND(OUTPUT toto.h toto.c
  COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/create_totoc_totoh.sh
 )
>>> SET_SOURCE_FILES_PROPERTIES(toto.h toto.c PROPERTIES GENERATETED TRUE)
>>>
>>> See:
>>> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set_source_files_properties
>>> and:
>>> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_sf:GENERATED
>>>
>>>
 INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR})
 ADD_LIBRARY(titi toto.c)
 ADD_LIBRARY(tata tata.c)
>>>
>>> Greetings
>>> Micha
>>>
>>
>>
>> the GENERATED property is set automatically by ADD_CUSTOM_COMMAND. But I
>> suspect the problem is that you used a relative path in your OUTPUT
>> option. *Always* specify full paths in the OUTPUT and DEPENDS options.
>> Also, make the custom command DEPENDS on the create_totoc_totoh.sh
>> script and it's input (perhaps it reads some configuration file or you
>> pass it another file as an argument, etc.).
> 
> Both solutions does not solve the problem.
> 
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
> ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/toto.h 
> ${CMAKE_CURRENT_SOURCE_DIR}/toto.c
>  COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/create_totoc_totoh.sh
> )
> SET_SOURCE_FILES_PROPERTIES(toto.h toto.c PROPERTIES GENERATETED TRUE)
> INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR})
> ADD_LIBRARY(titi toto.c)
> ADD_LIBRARY(tata tata.c)
> 
> The problem is that tata.c include toto.h. cmake does not know it 
> because C file dependencies are constructed later by make. The result is 
> that CMakeFiles/tata.dir/build.make does not include the rule needed to 
> construct toto.h. I try to find a way to add this rule.
> A workaround consists in putting toto.h in libtata dependencies but it's 
> not a dependency of libtata but a dependency of tata.c.

IMO, this isn't a workaround but the proper solution because the
dependency on toto.h actually doesn't consist for tata.c but for
tata.c.o and, thus, for the tata target, effectively. In other
words: Which action do you intend to perform in order to update
tata.c if toto.h has changed? Compiling updates the object file.
Alternatively, if the object file is newer than the header, and
the header is newer than the source file, is there a need to take
action? So, saying ADD_LIBRARY(tata tata.c toto.h) or setting the
OBJECT_DEPENDS property as Michael has proposed in the meantime is
certainly appropriate.

Regards,

Michael

> The error is :
> [ 33%] Building C object CMakeFiles/tata.dir/tata.c.o
> /home/vivien/tmp/cmake_deps/tata.c:1:18: fatal error: toto.h: No such 
> file or directory
> compilation terminated.
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Linking archives in a sibling directory

[Michael Hertling]

On 12/03/2010 04:26 PM, Raymond Wan wrote:
> Hi Michael,
> 
> Thank you for your continued advice!
> 
> 
> On Fri, Dec 3, 2010 at 19:13, Michael Hertling  wrote:
>> Nevertheless, I wonder why you want to build "main" by configuring its
>> own source directory and alternatively via the top-level directory. If
>> this is because you'd like to exclude some modules from building, you
>> should handle such things in the top-level CMakeLists.txt, e.g. like:
>>
>> # Define options:
>> OPTION(WITH_MAIN "Build module main" ON)
>> OPTION(WITH_A "Build module A" ON)
>> OPTION(WITH_B "Build module B" ON)
>>
>> # Handle dependencies:
>> IF(WITH_MAIN)
>>SET(WITH_A ON)
>> ENDIF()
>>
>> # Enable modules:
>> IF(WITH_B)
>>ADD_SUBDIRECTORY(dir-B)
>> ENDIF()
>> IF(WITH_A)
>>ADD_SUBDIRECTORY(dir-A)
>> ENDIF()
>> IF(WITH_MAIN)
>>ADD_SUBDIRECTORY(main)
>> ENDIF()
>>
>> So, you can conveniently enable/disable the modules on the command line
>> or in the GUI, e.g. with "cmake -DWITH_B=OFF "
>> if you don't want to build module B.
>>
>> As an alternative, you might consider to move dir-A to main/dir-A if
>> dir-A is essentially a submodule of main, but referring to a sibling
>> dir-A from main indicates that the latter is not sufficiently self-
>> contained to be built on its own with a "cmake ", so
>> the modules' relationships should be handled by other means, IMO.
> 
> 
> Hm, I see your point about why I'm providing support in a
> top-level CMakeLists.txt and a lower level one.  Perhaps I've simply
> confused myself and made things more complicated than it needs to be.
> Basically, what I want to do is, given this directory structure:
> 
> myproj/
>   +dirA/
>   +dirB/
>   +dirC/
>   +main1/
>   +main2/
>   +main3/
> 
> my final goal is that several programs (i.e., executables) will be
> made.  Let's say main1, main2, and main3.  The libraries dirA, ...,
> dirD are used by them and can also depend on each other with maybe
> even multiple levels of dependencies.  i.e.,
> 
> dirA --> dirB --> dirC
> 
> Any of these modules can be used by more than one program.  i.e.,
> 
> main1 --> dirA --> dirB --> dirC
> main2 --> dirC
> 
> My idea is that the top level CMakeLists.txt can create main1, main2,
> and main3.  The lower level CMakeLists.txt in dirA/, dirB/, and dirC/
> have their own main () which I am using to test them -- obviously,
> these main () functions are not linked into main1, main2, and main3.
> I only need them for development.  I think organizing dirA/, dirB/,
> and dirC/ within main1/, main2/, and main3/ isn't the way to go since
> these libraries are used by multiple executables.

Yes, absolutely, with such relations among executables and libraries,
their source directories should be siblings instead of descendants, and
the libraries' testing executables can be conveniently integrated using
ADD_TEST() without interfering with the main executables. However, when
your project grows and, hence, the number of source directories in the
project's root increases, say 10+, you should consider to organize them
further, e.g. like

myproj
  executables
main{1,2,3,...}
  libraries
dir{A,B,C,...}
  plugins
...

or

myproj
  source
core
  ...
gui
  ...
db
  ...

or whichever organizational criteria apply best, so the root directory
doesn't fill with countless source directories. Apart from that, there
is no need to have the top-level CMakeLists.txt create the main{1,2,3}
executables by itself; just add a CMakeLists.txt file in each of their
source directories as you do for the libraries, and use

ADD_SUBDIRECTORY(main1)
ADD_SUBDIRECTORY(main2)
ADD_SUBDIRECTORY(main3)

at the top level to enable them. In this way, you've a CMakeLists.txt
file in each of your project's source directories which does exactly
what needs to be done there, and the whole project is covered by the
top-level CMakeLists.txt with minimal assumptions w.r.t. the source
directories.

> Perhaps I should create and use the low-level CMakeLists.txt and when
> I am finished development, then create the top-level ones for just
> main1, main2, and main3.  In a way, I will only need to support either
> the top-level CMakeLists.txt or the lower level one and never both at
> the same time.  I guess I am ahead of myself and did both now, which
> is complicating things for me.

IMO, there is no reason to configure with lower-level CMakeLists.txt
files at first and switch to a top-level CMakeLists.txt later. Instead,
start right away with one

Re: [CMake] How to apply the --as-needed linker flag?

[Michael Hertling]

On 11/28/2010 09:10 AM, Alan W. Irwin wrote:
> On 2010-11-28 06:39+0100 Michael Hertling wrote:
> 
>> On 11/27/2010 06:45 PM, Alan W. Irwin wrote:
>>> I just discovered that many Linux distros these days use the
>>> --as-needed Linux linker option by default.  At first glance that
>>> option makes a lot of sense since it tends to reduce startup times.
>>> But I guess there are some caveats as well which is probably why CMake
>>> does not adopt this linker option by default for Linux builds.
>>> However, I would at least like to try this option for my own Linux
>>> builds without forcing it using target_link_libraries. Is it possible
>>> to specify linker options such as --as-needed using environment
>>> variables and/or -D options?
>>
>> On Linux, CMake takes account of the LDFLAGS environment variable
>> for the initial configuration of the build directory, so saying
>>
>> LDFLAGS="-Wl,--as-needed" cmake 
>>
>> enables "--as-needed" for this build directory - forever.
> 
> Thanks, Michael, that was exactly what I needed.  I was completely
> unaware that environment variable worked for CMake despite many years
> of using CMake on Linux.  Is the LDFLAGS environment variable
> documented for CMake anywhere?  I couldn't find it in the
> documentation you get with "cmake --help-full", and it is also not
> documented at http://www.cmake.org/Wiki/CMake_Useful_Variables. The
> useful environment variables CXXFLAGS, CFLAGS, and FFLAGS that allow
> you to specify general compiler flags in a convenient way are
> undocumented as well, and that is a real shame.

AFAIK, these variables aren't documented anywhere apart from
occasionally appearing on the mailing list. However, a quick

> grep "\\\$ENV{[A-Za-z0-9_]\+}" -r . | sed 
> "s%^.*\\\$ENV{\([A-Za-z0-9_]\+\)}.*\$%\1%" | sort -u

in the modules' directory reveals all of them which are read from
the environment. Apparently, the relevant ones are CC/CFLAGS, CXX/
CXXFLAGS, FC/FFLAGS, LDFLAGS, and RC/RCFLAGS for WIN32. Because of
their special meaning for a project's initial configuration, there
should be an enhancement of the useful-variables section, indeed.

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] providing library information, what's the cmake way

[Michael Hertling]

On 11/30/2010 05:53 AM, Kishore wrote:
> On Tuesday 23 Nov 2010 5:27:56 pm Johannes Zarl wrote:
>> Another somehow related topic seems to be import/export of targets. Should
>> a LibraryConfig.cmake or FindLibrary.cmake file create imported targets
>> for the library?
> 
> Thanks for this thread. It has helped. However, i am still not clear about 
> the use of the export/import feature. I thought that libraries built with 
> cmake would not need to write their Find*.cmake or *Config.cmake modules as 
> they could simply use the EXPORT feature.

No, the file created and installed by INSTALL(EXPORT ...) - casually
denoted as a "targets file" - contains information about the targets
provided by the package. The targets are set up as "IMPORTED" in the
targets file, and the latter must be included by *Config.cmake which
is still necessary. This is meant as a more flexible alternative to
explicit paths in XXX_LIBRARIES variables, e.g.; with targets files,
XXX_LIBRARIES contains the imported targets instead of the targets'
paths, so the different build types can be handled much better at
link time. The actual paths of the imported targets are specified
by means of IMPORTED_LOCATION properties in the targets file, too.

> It would be really helpful if someone could explain the proper use of these 
> features.

In [1,2], the machinery is explained quite well.

Regards,

Michael

[1]
[2]
___
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] providing library information, what's the cmake way

[Michael Hertling]

On 12/01/2010 05:57 PM, Johannes Zarl wrote:
> On 12/01/2010 at 16:06, Michael Hertling  wrote: 
>>> FIND_PACKAGE(XXX COMPONENTS YYY)
>>> ...
>>> ADD_SUBDIRECTORY(subdir)
>>> ...
>>> TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
>>> TARGET_LINK_LIBRARIES(BBB ${XXX_LIBRARIES} ${XXX_YYY_LIBRARIES})
>>>
>>> In subdir/CMakeLists.txt:
>>>
>>> FIND_PACKAGE(XXX COMPONENTS ZZZ)
>>> ...
>>> TARGET_LINK_LIBRARIES(subBBB ${XXX_LIBRARIES} ${XXX_ZZZ_LIBRARIES})
>>>
>>> As I mentioned above, I would expect XXX_LIBRARIES to contain only the
>>> base library, and find_package calls to act accumulatively.
>>
>> If I understand correctly, you'd like to have a set of variables like
>> XXX_*_{LIBRARIES,INCLUDE_DIRS,...} for each component instead of one
>> comprehensive set XXX_{LIBRARIES,INCLUDE_DIRS,...} for the entire
>> package including the components; this hasn't been obvious to me.
> 
> Correct.

>> The downside of your approach is that you have to mention component-
>> specific variables at various locations: For each component denoted
>> in the FIND_PACKAGE() invocation, you would usually have to mention
>>
>> - XXX_*_INCLUDE_DIRS in INCLUDE_DIRECTORIES()
>> - XXX_*_LIBRARIES in TARGET_LINK_LIBRARIES()
>> - XXX_*_DEFINITIONS in ADD_DEFINITIONS()
> 
> Which is less work than saving all three values for each target that
> I create.

It's not necessary to save these variables for each target. Typically,
it's necessary if there's more than one target in the CMakeLists.txt,
and two or more of them use the same package with a different set of
components; by far, this does not hold for all cases. Besides, when
loading multiple packages for multiple targets, it's not uncommon to
collect libraries in target-specific _LIBRARIES variables as
well as one collects a target's sources in _SOURCES, so the
only remaining overhead is an additional FIND_PACKAGE() call which
is inexpensive:

FIND_PACKAGE(A)
SET(T1_LIBRARIES ${A_LIBRARIES})
SET(T2_LIBRARIES ${A_LIBRARIES})

FIND_PACKAGE(B COMPONENTS B1)
LIST(APPEND T1_LIBRARIES ${B_LIBRARIES})
FIND_PACKAGE(B COMPONENTS B2)  # <-- That's all.
LIST(APPEND T2_LIBRARIES ${B_LIBRARIES})
...
TARGET_LINK_LIBRARIES(T1 ${T1_LIBRARIES})
TARGET_LINK_LIBRARIES(T2 ${T2_LIBRARIES})

A similar point might be applied to XXX_{INCLUDE_DIRS,DEFINITIONS}.

>> in addition to the package's base stuff, i.e. roughly speaking, with n
>> components you need to reference 3+3n variables. 
> 
> These 3+3n variables have to be defined, anyways (the find module needs 
> them internally, if it wants to compose XXX_INCLUDE_DIRS etc.).

Here, it's the user I have in mind, who possibly doesn't want to
fourfold specify each set of components requested from a package.

> Still, referencing the 3+3n variables are less work than having to
> define _and_ reference 3N variables (with N being the number of targets
> in your project). 

The need to save the results of a FIND_PACKAGE() call may come up for
targets within the same CMakeLists.txt file, but not unconditionally
for each of a project's targets. Additionally, this measure is taken
only if it's really necessary whereas your approach compels the user
to always refer to each component four times. Look at one of the
simplest configurations - one target and one package with two
components - the two approaches manifest like:

FIND_PACKAGE(XXX COMPONENTS YYY ZZZ)
ADD_DEFINITIONS(${XXX_DEFINITIONS}
${XXX_YYY_DEFINITIONS} ${XXX_ZZZ_DEFINITIONS})
INCLUDE_DIRECTORIES(${XXX_INCLUDE_DIRS}
${XXX_YYY_INCLUDE_DIRS} ${XXX_ZZZ_INCLUDE_DIRS})
ADD_EXECUTABLE(...)
TARGET_LINK_LIBRARIES(... ${XXX_LIBRARIES}
${XXX_YYY_LIBRARIES} ${XXX_ZZZ_LIBRARIES})

versus

FIND_PACKAGE(XXX COMPONENTS YYY ZZZ)
ADD_DEFINITIONS(${XXX_DEFINITIONS})
INCLUDE_DIRECTORIES(${XXX_INCLUDE_DIRS})
ADD_EXECUTABLE(...)
TARGET_LINK_LIBRARIES(... ${XXX_LIBRARIES})

It's quite obvious which approach means less work, and having only one
target in a CMakeLists.txt is no configuration I would denote as rare.

>> IMO, this thwarts the
>> idea of a multi-component package: Specifying components to adjust the
>> well-known and officially recommended package-related variables like
>> XXX_LIBRARIES. 
> 
> These variables are well-known and officially recommended for component-
> less packages only. Nobody bothered to write recommendations for
> component-packages yet.

${CMAKE_ROOT}/Modules/readme.txt mentions the XXX_YYY_EXECUTABLE and
XXX_YY_{LIBRARY,INCLUDE_DIR} variables explicitly, and IMO, wordings
as "YYY tool that comes with XXX" or "YY library that is part of the
XXX system" allow the general terms "tool" and "part"

Re: [CMake] find_package with ###Config.cmake

[Michael Hertling]

On 12/03/2010 08:45 AM, Andreas Pakulat wrote:
> On 03.12.10 07:11:23, Micha Renner wrote:
>> There is a small library "TLib" which is installed like this
>>
>> Install the project...
>> -- Install configuration: "Debug"
>> -- Installing: /usr/local/lib/libTLibd.so
>> -- Installing: /usr/local/lib/TLib/TLibExport.cmake
>> -- Installing: /usr/local/lib/TLib/TLibExport-debug.cmake
>> -- Installing: /usr/local/include/TLib/cmFile.h
>> -- Installing: /usr/local/lib/TLib/TLIBConfig.cmake
>> -- Installing: /usr/local/lib/TLib/TLIBConfigVersion.cmake
>>
>> The CMakeLists file for the application program has the following line
>> to find the library
>>
>> FIND_PACKAGE(TLIB)
>>
>> This works, surprisingly, very good. No CMAKE_MODULE_PATH, no TLIB_DIR
>> in this case. 
>>
>> But...
>>
>> If I call FIND_PACKAGE with version:
>> FIND_PACKAGE(TLIB 1.3)
>>
>> I get the std-warning:
>> -
>> CMake Warning at TestDLL/CMakeLists.txt:20 (FIND_PACKAGE):
>>   Could not find module FindTLIB.cmake or a configuration file for
>> package
>>   TLIB.
>>
>>   Adjust CMAKE_MODULE_PATH or TLIB_DIR...
>> -
>>
>>
>> Why can't CMake find the TLIBConfig file, if FIND_PACKAGE is called with
>> version and TLIB_DIR is not set? 
> 
> The problem might not be finding the Config file, but rather that the
> ConfigVersion file doesn't set the VERSION_COMPATIBLE or VERSION_EXACT
> variables. Or maybe it even sets the VERSION_UNSUITABLE to indicate that
> the installed version of TLib doesn't match the version you request.
> 
> Unfortunately cmake currently cannot seem to distinguish between these
> two cases (non-matching version vs. no config-file found), hence it
> produces the same message in both cases.

Meanwhile, with 2.8.3 to be exact, the warning message issued by CMake
if a version file is found but the requested version doesn't suit is:

Could not find a configuration file for package "..." that is compatible
with requested version "...".

The following configuration files were considered but not accepted:

  ..., version: ...

So, Micha, which CMake version do you use? If it's not 2.8.3 could you
give that a try and report the message if the problem still persists?
Additionally, the _CONSIDERED_{CONFIGS,VERSIONS} variables
would be of special interest, see dfe9c95.

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] Linking archives in a sibling directory

[Michael Hertling]

On 12/02/2010 03:13 PM, Raymond Wan wrote:
> Hi Michael,
> 
> 
> On Thu, Dec 2, 2010 at 19:40, Michael Hertling  wrote:
>> On 12/01/2010 06:03 PM, Raymond Wan wrote:
>>> Ah!  I see.  Then is it recommended that this top-level CMakeLists.txt
>>> have just these lines, or should I move the ADD_EXECUTABLE, etc. lines
>>> here as well?  Or is this really "up to me" and there isn't a
>>> suggested paradigm?
>>
>> Basically, IMO, a CMakeLists.txt with ADD_EXECUTABLE() et al. should be
>> placed in the same directory as the related source files unless there's
>> a reason not to do so; this makes for modularity and a well organized
>> code base. The above-mentioned directory structure with its top-level
>> CMakeLists.txt containing just ADD_SUBDIRECTORY() commands keeps the
>> modules main, dir-A and dir-B separate with minimal interconnections.
>> In the previous structure, e.g., main/CMakeLists.txt had to know that
>> dir-A resides in "../dir-A"; now, such information is concentrated in
>> the top-level CMakeLists.txt, and the sole reference of main to dir-A
>> is the target "subprogA_ar". Due to CMake's capabilities to track the
>> dependencies among targets, it doesn't matter where dir-A is placed
>> within the project's source tree. So, in short, don't move the
>> ADD_EXECUTABLE() etc. to the top-level CMakeLists.txt.
> 
> 
> I see -- I did not realize this point you made about CMake's
> dependency tracking abilities.  So, basically the only thing I need to
> worry about is the order of the ADD_SUBDIRECTORY ()'s.  As long as I
> put
> 
> ADD_SUBDIRECTORY (dir-A)
> 
> before
> 
> ADD_SUBDIRECTORY (main)
> 
> then "main" will be built correctly?

Even this is not necessary if the only reference of main to dir-A is
TARGET_LINK_LIBRARIES(... subprogA_ar) in main/CMakeLists.txt since
TARGET_LINK_LIBARIES(), AFAIK, does a lazy evaluation of the targets'
dependencies, i.e. they are evaluated when all CMakeLists.txt files
have been processed and, hence, all dependencies are known. If you
refer to subprogA_ar in another way, e.g. SET_TARGET_PROPERTIES(),
then you will get an error if dir-A hasn't been configured yet.

> But, if I am not mistaken and following what you are saying, I can
> only build "main" using the top-level CMakeLists.txt.  The lower
> CMakeLists.txt in main/ does not know the location of "dir-A".  The
> only way for both to work is to have this in main/CMakeLists.txt:
> 
> ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
> 
> yet this kind of duplication should be an error at worse; unnecessary
> repetition at best?

Each invocation of ADD_SUBDIRECTORY() for a source directory must be
associated with an own binary directory, so the above-mentioned line
would allow you to use both alternatives. However, when configuring
the top-level CMakeLists.txt, you will get an error due to multiple
definitions of the subprogA_ar target. In main/CMakeLists.txt, you
might protect ADD_SUBDIRECTORY() against multiple invocations like

IF(NOT TARGET subprogA_ar)
   ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
ENDIF()

or

IF(${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
   ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
ENDIF()

but this does not appear really appropriate to me.

Nevertheless, I wonder why you want to build "main" by configuring its
own source directory and alternatively via the top-level directory. If
this is because you'd like to exclude some modules from building, you
should handle such things in the top-level CMakeLists.txt, e.g. like:

# Define options:
OPTION(WITH_MAIN "Build module main" ON)
OPTION(WITH_A "Build module A" ON)
OPTION(WITH_B "Build module B" ON)

# Handle dependencies:
IF(WITH_MAIN)
SET(WITH_A ON)
ENDIF()

# Enable modules:
IF(WITH_B)
ADD_SUBDIRECTORY(dir-B)
ENDIF()
IF(WITH_A)
ADD_SUBDIRECTORY(dir-A)
ENDIF()
IF(WITH_MAIN)
ADD_SUBDIRECTORY(main)
ENDIF()

So, you can conveniently enable/disable the modules on the command line
or in the GUI, e.g. with "cmake -DWITH_B=OFF "
if you don't want to build module B.

As an alternative, you might consider to move dir-A to main/dir-A if
dir-A is essentially a submodule of main, but referring to a sibling
dir-A from main indicates that the latter is not sufficiently self-
contained to be built on its own with a "cmake ", so
the modules' relationships should be handled by other means, IMO.

Regards,

Michael

>> The top-level directory of non-trivial projects should not contain any
>> source files, perhaps a config.h header or the like. Usually, there're
>> enough 

Re: [CMake] Linking archives in a sibling directory

[Michael Hertling]

On 12/01/2010 06:03 PM, Raymond Wan wrote:
> Hi Michael,
> 
> 
> On Thu, Dec 2, 2010 at 01:03, Michael Hertling  wrote:
>> On 12/01/2010 08:18 AM, Raymond Wan wrote:
>>> Hi all,
>>>
>>> I'm having a problem understanding how I can link to an archive in
>>> another directory which is not a subdirectory. For example:
>>>
>>> myproj
>>>   +-- main
>>> +-- CMakeLists.txt
>>> +-- source files for main program
>>>   +-- dir-A
>>> +-- CMakeLists.txt
>>> +-- source files for sub-program A
>>>   +-- dir-B
>>> +-- CmakeLists.txt
>>> +-- source files for sub-program B
>>
>> This error is caused by the fact that the directory "dir-A" is outside
>> the "main" directory tree, so dir-A's binary directory would likewise
>> be outside main's binary tree, and this is reasonably forbidden when
>> configuring "main". You might specify dir-A's binary directory in
>> main/CMakeLists.txt explicitly, e.g.:
>>
>> ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
>>
>> Hence, subprogA_ar will be built within the binary tree's "dir-A".
> 
> 
> Ah!  I see now.  I didn't realize I could prepend a path like that.  I
> was trying to find some kind of "ADD_DIRECTORY" command which had this
> restriction removed.  But then I realized if I'm looking for something
> like that, there might be a bigger problem in terms of how I'm
> organizing things...
> 
> 
>>> myproj
>>>   +-- main
>>> +-- CMakeLists.txt
>>> +-- source files for main program
>>> +-- dir-A
>>>   +-- source files for sub-program A
>>> +-- dir-B
>>>   +-- source files for sub-program B
>>>
>>>
>>> Is this what I should have done??
>>
>> As an alternative, consider to add a CMakeLists.txt in "myproj"
>>
>> CMAKE_MINIMUM_REQUIRED(...)
>> PROJECT(myproj)
>> ADD_SUBDIRECTORY(dir-A)
>> ADD_SUBDIRECTORY(dir-B)
>> ADD_SUBDIRECTORY(main)
>>
>> and subsequently, configure this directory instead of "main".
> 
> 
> Ah!  I see.  Then is it recommended that this top-level CMakeLists.txt
> have just these lines, or should I move the ADD_EXECUTABLE, etc. lines
> here as well?  Or is this really "up to me" and there isn't a
> suggested paradigm?

Basically, IMO, a CMakeLists.txt with ADD_EXECUTABLE() et al. should be
placed in the same directory as the related source files unless there's
a reason not to do so; this makes for modularity and a well organized
code base. The above-mentioned directory structure with its top-level
CMakeLists.txt containing just ADD_SUBDIRECTORY() commands keeps the
modules main, dir-A and dir-B separate with minimal interconnections.
In the previous structure, e.g., main/CMakeLists.txt had to know that
dir-A resides in "../dir-A"; now, such information is concentrated in
the top-level CMakeLists.txt, and the sole reference of main to dir-A
is the target "subprogA_ar". Due to CMake's capabilities to track the
dependencies among targets, it doesn't matter where dir-A is placed
within the project's source tree. So, in short, don't move the
ADD_EXECUTABLE() etc. to the top-level CMakeLists.txt.

> I guess I chose my first directory layout because the source in a
> directory (i.e., dir-A) can be several dependencies down and it can
> even be used by two targets in two different directories.  So, I
> figured that keeping them all at the "same directory level" would be
> best.  But it seems what you're suggesting here seems better -- never
> thought of it; the "myproj" directory has no files in it...just
> directories right now...

The top-level directory of non-trivial projects should not contain any
source files, perhaps a config.h header or the like. Usually, there're
enough things gathering in a project's root, e.g. READMEs, subdirs for
documentation, resources or CMake stuff, a CMakeLists.txt file ;) etc.
The sources, however, should be organized in their own subdirectories,
so the top-level CMakeLists.txt typically contains ADD_SUBDIRECTORY()
commands along with configurational stuff like setting up compiler
flags, processing options or investigating the underlying system,
but no ADD_EXECUTABLE() or the like.

Of course, there're exceptions and probably strong different opinions.

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] Linking archives in a sibling directory

[Michael Hertling]

On 12/01/2010 08:18 AM, Raymond Wan wrote:
> Hi all,
> 
> I'm having a problem understanding how I can link to an archive in
> another directory which is not a subdirectory. For example:
> 
> myproj
>   +-- main
> +-- CMakeLists.txt
> +-- source files for main program
>   +-- dir-A
> +-- CMakeLists.txt
> +-- source files for sub-program A
>   +-- dir-B
> +-- CmakeLists.txt
> +-- source files for sub-program B
> 
> 
> Basically, I would like to make a larger project (main) and I'm
> building and testing each of its components separately.
> 
> Right now, the main's CMakeLists.txt looks something like this:
> 
> 
> INCLUDE_DIRECTORIES (../dir-A)
> SUBDIRS (../dir-A)
> ADD_EXECUTABLE (main ${MAIN_SRCS})
> TARGET_LINK_LIBRARIES (main subprogA_ar)
> 
> 
> which works fine so far (the CMakeLists.txt in dir-A generates the
> archive subprogA_ar).
> 
> However, I just found out that SUBDIRS is deprecated and so, replaced
> it with "ADD_SUBDIRECTORY".  That's when I got an error about "dir-A"
> not being a subdirectory.  Obviously, I was not using "SUBDIRS" before
> as it was intended...  :-)

This error is caused by the fact that the directory "dir-A" is outside
the "main" directory tree, so dir-A's binary directory would likewise
be outside main's binary tree, and this is reasonably forbidden when
configuring "main". You might specify dir-A's binary directory in
main/CMakeLists.txt explicitly, e.g.:

ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)

Hence, subprogA_ar will be built within the binary tree's "dir-A".

> I've also tried adding "dir-A" as a LINK_DIRECTORIES with no success.
> It is unable to find subprogA_ar.
> 
> I'm not sure if it is possible, but ideally, when I run "make" in
> main/, I would like it to rebuild the targets in "dir-A" (including
> the archive) and link that in.
> 
> I'm also open to the possibility that I got the above organization all
> wrong and should have only one large CMakeLists.txt in a directory
> structure like this:
> 
> 
> myproj
>   +-- main
> +-- CMakeLists.txt
> +-- source files for main program
> +-- dir-A
>   +-- source files for sub-program A
> +-- dir-B
>   +-- source files for sub-program B
> 
> 
> Is this what I should have done??

As an alternative, consider to add a CMakeLists.txt in "myproj"

CMAKE_MINIMUM_REQUIRED(...)
PROJECT(myproj)
ADD_SUBDIRECTORY(dir-A)
ADD_SUBDIRECTORY(dir-B)
ADD_SUBDIRECTORY(main)

and subsequently, configure this directory instead of "main".

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] (no subject)

[Michael Hertling]

On 12/01/2010 03:45 PM, Gary%20G.%20Little%20%40%20comcast wrote:
> I have a Visual Studio 2010 solution and I am trying to set the 
> Configuration Properties -> General -> Platform Toolset of one 
> particular project to use V90 to allow this project to build with the VS 
> 2008 tool set. I followed an older thread and tried this: 
> 
> set_target_properties(WindowsApplication${version} PROPERTIES 
> PlatformToolset "V90") 
> 
> That results in an error: "set_target_properties Can not find target to 
> add properties to". ${version} is set to a version string and the term 
> WindowsApplication${version} is used later in the file by an 
> "add_library" and a "target_link_library with no error. How can I set the 
> platform toolset to V90 from CMAKE? 

SET_TARGET_PROPERTIES() must not appear before the targets it
operates on, so move this command behind the ADD_LIBRARY().

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] providing library information, what's the cmake way

[Michael Hertling]

On 11/30/2010 01:32 PM, Johannes Zarl wrote:

 - Do multiple consecutive FIND_PACKAGE(XXX ...) invocations act in an
 accumulative manner on the invocation-specific variables?
>>>
>>> Generally speaking, I would say: yes. At least this is the way of the
>>> least surprise for the user, as in sufficiently complex projects a
>>> package may be included at different places with different arguments.
>>
>> For the same reason, I'd tend to the opposite; look at the following:
>>
>> FIND_PACKAGE(XXX COMPONENTS YYY)
>> ...
>> ADD_SUBDIRECTORY(subdir)
>>
>> In subdir/CMakeLists.txt:
>>
>> FIND_PACKAGE(XXX COMPONENTS ZZZ)
>> ...
>> TARGET_LINK_LIBRARIES(... ${XXX_LIBRARIES})
>>
>> Here, the target is also linked against XXX_YYY_LIBRARY as the latter is
>> inherited via XXX_LIBRARIES from the parent directory, but if the target
>> only needs XXX_ZZZ_LIBRARY it will possibly be overlinked. Although this
>> can be avoided by resetting XXX_LIBRARIES before each FIND_PACKAGE()
>> invocation, I don't think that's the way one would like to go.
>>
>> IMO, the invocation-specific results of any FIND_PACKAGE() call should
>> depend solely on the parameters passed in and the well-known variables
>> like CMAKE_PREFIX_PATH. The downside is that one must possibly process
>> or save the results before they could be overwritten, e.g.:
>>
>> FIND_PACKAGE(XXX REQUIRED YYY)
>> SET(LIBRARIES ${XXX_LIBRARIES})
>> FIND_PACKAGE(XXX COMPONENTS ZZZ)
>> LIST(APPEND LIBRARIES ${XXX_LIBRARIES})
>> ...
>> TARGET_LINK_LIBRARIES(... ${LIBRARIES})
>>
>> Since such related calls to FIND_PACKAGE(XXX ...) usually occur nearby
>> each other within the same CMakeLists.txt, this little penalty should
>> be acceptable whereas accumulated XXX_LIBRARIES and the like may have
>> far reaching and surprising effects, especially in complex projects.
>
> Funny enough, my example is almost the same:
>
> FIND_PACKAGE(XXX COMPONENTS YYY)
> ...
> ADD_SUBDIRECTORY(subdir)
> ...
> TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
> TARGET_LINK_LIBRARIES(BBB ${XXX_LIBRARIES} ${XXX_YYY_LIBRARIES})
>
> In subdir/CMakeLists.txt:
>
> FIND_PACKAGE(XXX COMPONENTS ZZZ)
> ...
> TARGET_LINK_LIBRARIES(subBBB ${XXX_LIBRARIES} ${XXX_ZZZ_LIBRARIES})
>
> As I mentioned above, I would expect XXX_LIBRARIES to contain only the
> base library, and find_package calls to act accumulatively.

If I understand correctly, you'd like to have a set of variables like
XXX_*_{LIBRARIES,INCLUDE_DIRS,...} for each component instead of one
comprehensive set XXX_{LIBRARIES,INCLUDE_DIRS,...} for the entire
package including the components; this hasn't been obvious to me.

Nevertheless, what do you understand by "accumulative" in this regard,
i.e. what accumulates in which variables if FIND_PACKAGE() is invoked
multiple times and each component has an independent set of variables
separate from the package's base stuff?

> If it was otherwise, then target AAA would be overlinked, and BBB would
> probably fail to link. Even without the ADD_SUBDIRECTORY the situation
> would be far from ideal: in order to avoid overlinking of BBB I have to
> make an additional find_package invocation. In a worst-case scenario one
> would need multiple find_package invocations for the same packages before
> each target!

At first, BBB could not fail to link due to the FIND_PACKAGE() in the
subdir/CMakeLists.txt because the XXX_LIBRARIES variable in the parent
directory is not modified unless the find module uses the PARENT_SCOPE
option of SET(), but there's no reason to do so as it is pretty unwise.

In contrast, the potential overlinking of AAA is a point, indeed, as it
is generally with multiple targets, each depending on an individual set
of components, within the same CMakeLists.txt. Here, I'd actually need
to call FIND_PACKAGE() multiple times and immediately process/save the
variables like XXX_LIBRARIES if they're really invocation-specifically
populated, but I'm in doubt whether this can be reckoned as "far from
ideal". Note that because of CMake's caching, repeated invocations of
FIND_PACKAGE() don't tend to be expensive, so

FIND_PACKAGE(XXX COMPONENTS base)
TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
FIND_PACKAGE(XXX COMPONENTS base YYY)
TARGET_LINK_LIBRARIES(BBB ${XXX_LIBRARIES})

is nothing I'd be afraid of. Moreover, in subdir/CMakeLists.txt, you
have to call FIND_PACKAGE() anew anyway, as you've also when mixing
optional and required components with a usage of the REQUIRED flag.

> The "accumulative scenario" of find_package without side-effects of the
> components on the XXX_LIBRARIES is far more transparent:
> If you link against XXX_LIBRARIES, you know exactly what you are linking
> against, regardless of who called find_package(XXX) with whatever
> components since you did your find_package call. You don't even have to
> backup your XXX_LIBRARIES and other variables, because they are not
altered.

The downside of your approach is that you have to mention component-
specific variables at various location

Re: [CMake] Problems to find xmlrpc_server_abyss++.so on FreeBSD

[Michael Hertling]

On 11/30/2010 12:27 AM, Renato Botelho wrote:
> On Mon, Nov 29, 2010 at 9:20 PM, Renato Botelho  wrote:
>> Hi,
>>
>> It's the first project i'm migrating from autotools to cmake,
>> and it's going really well, in 4 days it's almost done. \o/
>>
>> The only issue I have now is following, i have this code
>> on my CMakeLists.txt:
>>
>> find_package (XMLRPC REQUIRED abyss-server c++2)
> 
> It's always the same, one entire day trying to figure it out and
> 5 seconds after sending this email i found, i just changed the
> order of components (c++2 abyss-server) and it detected my
> xmlrpc fine. It's fixed now. The other problem below still persists.
> 
>> Ah, since i'm talking about FindXMLRPC, I used REQUIRED
>> param, like i showed above, but if it doesn't find xmlrpc
>> it shows an error message but don't stop, i needed to add
>> this:
>>
>> if (NOT XMLRPC_FOUND)
>>  message (FATAL_ERROR "XMLRPC-C not found")
>> endif (NOT XMLRPC_FOUND)
>>
>> Is it the expected behavior?
> 
> It persists

AFAICS, this is due to the last code snippet in FindXMLRPC.cmake:

# Report the results.
IF(NOT XMLRPC_FOUND)
  SET(XMLRPC_DIR_MESSAGE
"XMLRPC was not found. Make sure the entries XMLRPC_* are set.")
  IF(NOT XMLRPC_FIND_QUIETLY)
MESSAGE(STATUS "${XMLRPC_DIR_MESSAGE}")
  ELSE(NOT XMLRPC_FIND_QUIETLY)
IF(XMLRPC_FIND_REQUIRED)
  MESSAGE(FATAL_ERROR "${XMLRPC_DIR_MESSAGE}")
ENDIF(XMLRPC_FIND_REQUIRED)
  ENDIF(NOT XMLRPC_FIND_QUIETLY)
ENDIF(NOT XMLRPC_FOUND)

If XMLRPC_FOUND is FALSE the MESSAGE(FATAL_ERROR ...) is emitted only
if XMLRPC_FIND_REQUIRED is TRUE - that's OK - and XMLRPC_FIND_QUIETLY
is TRUE also - which is wrong. IMO, the REQUIRED flag must absolutely
take precedence over the QUIET flag, e.g.:

IF(NOT XMLRPC_FOUND)
IF(XMLRPC_FIND_REQUIRED)
MESSAGE(FATAL_ERROR ...)
ELSEIF(NOT XMLRPC_FIND_QUIETLY)
MESSAGE(STATUS ...)
ENDIF()
ENDIF()

This is the pattern used by FIND_PACKAGE_HANDLE_STANDARD_ARGS(), too.
As it's done currently in FindXMLRPC.cmake, you must enable REQUIRED
*and* QUIET to make the find module bail out *with* a message if the
package hasn't been found.

As a general interpretation of the REQUIRED flag, the user does not
want to check whether the package has been found if FIND_PACKAGE()
returns, or vice versa: If there is any need to check whether the
requested stuff is actually present, the REQUIRED flag is useless.
In particular, this should apply also to the components of multi-
component packages.

Feel encouraged to file a bug report.

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] providing library information, what's the cmake way

[Michael Hertling]

On 11/29/2010 02:28 PM, Johannes Zarl wrote:
> Sorry for the late response, but your mail was simply to long for a
> swift response...

No problem, this topic is not exactly trivial.

> On 11/26/2010 at 05:47, Michael Hertling  wrote: 
>> On 11/24/2010 04:51 PM, Johannes Zarl wrote:
>>> About the components question again: I played around a bit, and I think I 
>>> now more or less have comprehended this. I guess for a package XXX with 
>>> components YYY and ZZZ, one could set variables XXX_HAS_YYY and XXX_HAS_ZZZ
>>> and then use a loop like this one in the XXXConfig.cmake file:
>>>
>>> foreach( component ${XXX_FIND_COMPONENTS} )
>>> if ( XXX_HAS_${component})
>>> set ( XXX_${component}_FOUND TRUE )
>>> else( XXX_HAS_${component})
>>> if ( ${XXX_FIND_REQUIRED})
>>> message(FATAL_ERROR "Required component ${component} not 
>> found!")
>>> elseif ( NOT XXX_FIND_QUIETLY)
>>> message(STATUS "Component ${component} not found!")
>>> endif ( ${XXX_FIND_REQUIRED})
>>> endif ( XXX_HAS_${component})
>>> endforeach( component )
>>>
>>> Correct?
>>
>> While that's a possible approach it lacks the invocation-specific
>> variables, i.e. XXX_{INCLUDE_DIRS,LIBRARIES,DEFINITIONS}, and in
>> some cases, these can't be assembled in a simple component-wise
>> manner, see below. Moreover, there are further questions w.r.t.
>> multi-component packages and their config files:
> 
> Does this mean that XXX_LIBRARIES etc. should normally incorporate the
> settings for the components as well? [...]

Yes, of course, if FIND_PACKAGE(XXX ...) returns successfully one would
expect XXX_LIBRARIES to hold all libraries necessary to link against in
order to use all components enabled by the FIND_PACKAGE() invocation,
i.e. the libraries provided by the components themselves as well as
their prerequisites.

> [...] IMO this can't work if you call
> find_package several times with different components. [...]

This is one of those questions to deal with when it comes to multi-
component packages: Does FIND_PACKAGE(XXX ...) act accumulatively?

> [...] Also, this would 
> make it impossible to link to the "base library" alone, i.e. without
> the components...

One might consider the base library as a component by itself, perhaps
enabled automatically by resolving inter-component dependencies. As an
alternative, one could a priori populate XXX_LIBRARIES et al. with the
base library stuff and add the components' contributions as required.
Furthermore, a package doesn't need to have a dedicated base library,
e.g. Boost hasn't, and if you don't specify any components the
Boost_LIBRARIES variable remains empty.

>> - Does the config file provide the component-specific variables like
>> XXX_YYY_FOUND for each available component or for the requested ones
>> only, i.e. can you rely on XXX_ZZZ_FOUND to have a definite value if
>> you just said FIND_PACKAGE(XXX COMPONENTS YYY)? With your foregoing
>> approach, you can't. That's alright, but should be mentioned in the
>> package's documentation. Imagine the following scenario: There's one
>> installation of XXX for the native system and another one for cross
>> compiling purposes. The latter has YYY and ZZZ while the former has
>> YYY only. Due to FIND_PACKAGE()'s ability to search for config files
>> in various locations, such a coexistence is easily possible. Now, a
>> FIND_PACKAGE(XXX COMPONENTS YYY ZZZ) for the cross compilation XXX
>> returns with XXX_ZZZ_FOUND=TRUE, but does a subsequent invocation of
>> FIND_PACKAGE(XXX COMPONENTS YYY) within the same scope for the native
>> XXX return with XXX_ZZZ_FOUND=FALSE, or does XXX_ZZZ_FOUND=TRUE still
>> hold from the previous invocation? Both alternatives are fine, but the
>> user should know the score. 
> 
> Thanks, I hadn't thought of this. So the code-snippet above should 
> contain a "set ( XXX_${component}_FOUND ${component}-NOTFOUND )".

Yes, one would expect that FOUND variables for requested components
receive defined values in all cases - positive as well as negative.

>> Besides, it's a good style to refer to any
>> component-related variables only if the particular component has been
>> requested explicitly.
> 
> Ok, so a better style would be to only set the XXX_HAS_* variables at 
> first (maybe unsetting them at the end of the config file?), and then
> to conditionally set the XXX_YYY_INCLUDE_DIRS etc. if XXX_YYY_FOUND
> is true.

Here, I meant it is a good *user* style to rely only on varia

Re: [CMake] Relink on library rebuild dilema

[Michael Hertling]

On 11/29/2010 05:05 AM, Bill Hoffman wrote:
> On 11/28/2010 3:19 AM, Sebastian Schaetz wrote:
>> Michael Hertling  writes:
>>
>>> 1) In the top-level CMakeLists.txt, you might say
>>>
>>> SET_SOURCE_FILES_PROPERTIES(
>>>  main.cpp PROPERTIES OBJECT_DEPENDS
>>>  ${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a
>>> )
>>>
>>> When libkernel_executable.a has changed, this results in recompiling
>>> main.cpp - a penalty - and the desired relinking of main_target. If
>>> main.cpp's recompilation is expensive you may possibly add an empty
>>> cpp file to main_target's sources and impose the property on that.
>>>
>>
>> Wow, those suggestions all sound great and I'm completely unfamiliar with 
>> them
>> (so I think there's a good chance they will work). I will try them as soon as
>> possible! Thanks a lot for the suggestions.
>>
> 
> No need for all the complication...
> 
> If you already know where the library is going to be:
> 
>   ${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a
> 
> Then link directly to the full path:
> 
> target_link_libraries(main_target
>   ${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a)
> 
> Now the makefiles will depend on that file and it will relink when that 
> .a changes.   This is why link_directories/*link_libraries without a 
> full path to the library is almost always a bad idea...

Oops, the simplest solution at all. ~8) Thanks for pointing it out, Bill.

Perhaps, this is a good opportunity to ask a related question: Some
time ago, there has been an issue with special linker scripts which
are part of a project. Of course, one would like to see the linker
triggered when these scripts change, and the best solution I have
found so far is - just like suggested to the OP -

- a dummy source file to impose the OBJECT_DEPENDS property on, or
- a dummy static library that is invalidated when the scripts change
  and (mis)used to force a dependency of the link line on the scripts.

Both alternatives are not really satisfying, so I wonder if there is any
smarter and more direct possibility to establish a file-level dependency
of the link line on an arbitrary file that's not mentioned as a library
in TARGET_LINK_LIBRARIES(). For Makefiles, this involves just a single
additional line.

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] How to apply the --as-needed linker flag?

[Michael Hertling]

On 11/27/2010 06:45 PM, Alan W. Irwin wrote:
> I just discovered that many Linux distros these days use the
> --as-needed Linux linker option by default.  At first glance that
> option makes a lot of sense since it tends to reduce startup times.
> But I guess there are some caveats as well which is probably why CMake
> does not adopt this linker option by default for Linux builds.
> However, I would at least like to try this option for my own Linux
> builds without forcing it using target_link_libraries. Is it possible
> to specify linker options such as --as-needed using environment
> variables and/or -D options?

On Linux, CMake takes account of the LDFLAGS environment variable
for the initial configuration of the build directory, so saying

LDFLAGS="-Wl,--as-needed" cmake 

enables "--as-needed" for this build directory - forever.

If you need more flexibility you might say, e.g.,

SET_TARGET_PROPERTIES(... PROPERTIES LINK_FLAGS "$ENV{MYLDFLAGS}")

and use the MYLDFLAGS environment variable to reconfigure later:

MYLDFLAGS="-Wl,--no-as-needed" cmake 

'hope that helps.

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] Relink on library rebuild dilema

[Michael Hertling]

On 11/26/2010 05:00 PM, Sebastian Schaetz wrote:
> Hi,
> 
> I have a somewhat weird setup to build binaries for the Cell processor:
> 
> |-- CMakeLists.txt
> |-- kernels
> |   |-- CMakeLists.txt
> |   `-- kernel.cpp
> `-- main.cpp
> 
> From the main.cpp in the root directory the executable is built. 
> 
> In the kernels folder strange things (have to) happen: first the kernel.cpp is
> compiled with a custom compiler (I use a combination of SET, CMAKE_C_COMPILER
> and ADD_EXECUTABLE), then this binary is converted into a library using a 
> custom
> POST_BUILD command that calls a special tool to do just that. If the binary is
> called kernel_executable_bin, the custom command generates a file
> libkernel_executable.a
> 
> Now I have to link this library to my main executable (built from main.cpp).
> What I did so far is to put in the kernels/CMakeLists.txt file:
> 
> add_dependencies(main_target kernel_executable_bin)
> 
> and in the /CMakeLists.txt file:
> 
> link_directories("${CMAKE_CURRENT_BINARY_DIR}/kernels/")
> target_link_libraries(main_target kernel_executable)
> 
> This works as expected for one ugly flaw: if I only change kernels/kernel.cpp 
> it
> won't relink the main_target. I have thus far been unsuccessful in getting 
> this
> to work. I've tried various combinations of add_library(STATIC IMPORTED) and
> add_custom_target(DEPENDS) but it won't work.
> 
> Any ideas would be greatly appreciated.

Despite TARGET_LINK_LIBRARIES(), there's no dependency of main_target
on libkernel_executable.a, so main_target isn't relinked if the kernel
stuff is rebuilt. Nevertheless, there're some approaches I could offer:

1) In the top-level CMakeLists.txt, you might say

SET_SOURCE_FILES_PROPERTIES(
main.cpp PROPERTIES OBJECT_DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a
)

When libkernel_executable.a has changed, this results in recompiling
main.cpp - a penalty - and the desired relinking of main_target. If
main.cpp's recompilation is expensive you may possibly add an empty
cpp file to main_target's sources and impose the property on that.

2) In kernels/CMakeLists.txt, add the following lines

FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/empty.c)
ADD_LIBRARY(empty STATIC empty.c)
ADD_CUSTOM_COMMAND(TARGET kernel_executable_bin POST_BUILD COMMAND
${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/empty.c
)

or enhance the custom command which creates libkernel_executable.a from
kernel_executable_bin by the "cmake -E touch" shown above. Finally, in
the top-level CMakeLists.txt, say:

TARGET_LINK_LIBRARIES(main_target kernel_executable empty)

When kernels/kernel.cpp has changed the kernel_executable_bin and
libkernel_executable.a are rebuilt as usual, but kernels/empty.c is
touched by the way. This results in rebuilding libempty.a which in turn
makes main_target be relinked since it depends on the empty library. If
there's trouble with an empty static library just write some dummy code
in kernels/empty.c that you don't refer to from anywhere in the project.

3) If you get along with Makefiles you may possibly use a script in
junction with the RULE_LAUNCH_LINK target property to generate the
libkernel_executable.a from kernel_executable_bin as an actual
target like

ADD_LIBRARY(kernel_executable STATIC "")
ADD_DEPENDENCIES(kernel_executable kernel_executable_bin)

so the TARGET_LINK_LIBRARIES(main_target kernel_executable) in the
top-level CMakeLists.txt should be sufficient to trigger the linker.

'hope that helps.

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] set_source_files_properties for includedirectories

[Michael Hertling]

On 11/26/2010 09:40 AM, Andrea Galeazzi wrote:
> Michael Hertling ha scritto:
>> On 11/23/2010 03:23 PM, Andrea Galeazzi wrote:
>>
>>> Marcel Loose ha scritto:
>>>  
>>>>>>> On 23-11-2010 at 10:55, in message<4ceb8f76.80...@korg.it>, Andrea
>>>>>>>
>>>>>>>  
>>>> Galeazzi
>>>>   wrote:
>>>>
>>>>
>>>>> In a project I've got two groups of files having different include
>>>>> paths. These paths have some conflicts so I need to specify just one
>>>>>
>>>>>  
>>>>
>>>>
>>>>> for each file requires it.
>>>>> My first idea was to apply set_source_files_properties with a
>>>>>
>>>>>  
>>>> property
>>>>
>>>>
>>>>> like include_directories but I don't find anything similar. My next
>>>>> attempt is gonna use the COMPILE_FLAGS property, does anybody know a
>>>>>
>>>>>  
>>>>
>>>>
>>>>> more efficient and elegant way to accomplish a such task?
>>>>> An equivalent issue was discussed in this thread
>>>>> http://www.mail-archive.com/cmake@cmake.org/msg05276.html  but I
>>>>>
>>>>>  
>>>> didn't
>>>>
>>>>
>>>>> find any useful answer.
>>>>> ___
>>>>> Powered bywww.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
>>>>>
>>>>>  
>>>> Hi Andrea,
>>>>
>>>> As you noted include_directories is a per-directory setting. So, if
>>>> you're free to reorganize your source files, you could put the two
>>>> groups of files in two different directories. Then you can use
>>>> include_directories() in each directory. Make sure you don't make one of
>>>> these directories a subdirectory of the other.
>>>>
>>>> HTH,
>>>> Marcel Loose.
>>>>
>>>>
>>>> __ Informazioni da ESET NOD32 Antivirus, versione del database 
>>>> delle firme digitali 5639 (20101122) __
>>>>
>>>> Il messaggioè  stato controllato da ESET NOD32 Antivirus.
>>>>
>>>> www.nod32.it
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Yes, the sources are splitted in different directories but the
>>> CMakeLists.txt is just one:
>>> -Root
>>>CMakeLists.txt
>>>-dir1
>>>  file1.cpp
>>>  file2.cpp
>>>  ..
>>>-dir2
>>>   file1.cpp
>>>   file2.cpp
>>>   .
>>> I'd like to generate just one IDE project from this project.
>>>  
>>
>> FYI, see [1] and especially [2].
>>
>> Regards,
>>
>> Michael
>>
>> [1]http://public.kitware.com/Bug/view.php?id=1968
>> [2]http://public.kitware.com/Bug/view.php?id=8189
>> ___
>> Powered bywww.kitware.com
>>
>> Visit other Kitware open-source projects 
>> athttp://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
>>
>> __ Informazioni da ESET NOD32 Antivirus, versione del database delle 
>> firme digitali 5647 (20101125) __
>>
>> Il messaggioè  stato controllato da ESET NOD32 Antivirus.
>>
>> www.nod32.it
>>
>>
>>
>>
>>
> Sorry, I don't understand, what's [1] or [2]?

These are the references at the foot of my post; since citations of
URLs, books etc. tend to be quite long it's handy to use numbered
placeholders instead of embedding them in the text immediately.

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] set_source_files_properties for includedirectories

[Michael Hertling]

On 11/23/2010 03:23 PM, Andrea Galeazzi wrote:
> Marcel Loose ha scritto:
> On 23-11-2010 at 10:55, in message <4ceb8f76.80...@korg.it>, Andrea
> 
>> Galeazzi
>>  wrote: 
>>   
>>> In a project I've got two groups of files having different include 
>>> paths. These paths have some conflicts so I need to specify just one 
>>> 
>>
>>   
>>> for each file requires it.
>>> My first idea was to apply set_source_files_properties with a
>>> 
>> property 
>>   
>>> like include_directories but I don't find anything similar. My next 
>>> attempt is gonna use the COMPILE_FLAGS property, does anybody know a
>>> 
>>
>>   
>>> more efficient and elegant way to accomplish a such task?
>>> An equivalent issue was discussed in this thread 
>>> http://www.mail-archive.com/cmake@cmake.org/msg05276.html but I
>>> 
>> didn't 
>>   
>>> find any useful answer.
>>> ___
>>> 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
>>> 
>>
>> Hi Andrea,
>>
>> As you noted include_directories is a per-directory setting. So, if
>> you're free to reorganize your source files, you could put the two
>> groups of files in two different directories. Then you can use
>> include_directories() in each directory. Make sure you don't make one of
>> these directories a subdirectory of the other.
>>
>> HTH,
>> Marcel Loose.
>>
>>
>> __ Informazioni da ESET NOD32 Antivirus, versione del database delle 
>> firme digitali 5639 (20101122) __
>>
>> Il messaggio è stato controllato da ESET NOD32 Antivirus.
>>
>> www.nod32.it
>>
>>
>>
>>
>>   
> Yes, the sources are splitted in different directories but the 
> CMakeLists.txt is just one:
> -Root
>   CMakeLists.txt
>   -dir1
> file1.cpp
> file2.cpp
> ..
>   -dir2
>  file1.cpp
>  file2.cpp
>  .
> I'd like to generate just one IDE project from this project.

FYI, see [1] and especially [2].

Regards,

Michael

[1] http://public.kitware.com/Bug/view.php?id=1968
[2] http://public.kitware.com/Bug/view.php?id=8189
___
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] providing library information, what's the cmake way

[Michael Hertling]

On 11/24/2010 04:51 PM, Johannes Zarl wrote:
> Hi,
> 
> On 11/23/2010 at 21:25, Alexander Neundorf  wrote: 
>> CMAKE_MODULE_PATH is only for finding Find-modules, not for finding the 
>> actual packages or Config-files.
>> For that you can set CMAKE_PREFIX_PATH. CMake uses each directory contained 
>> in CMAKE_PREFIX_PATH for all its find_program/file/path/library/package() 
>> calls to search in the respective subdirectories for the 
>> executables/files/libraries/Config-files.
> 
> Thanks for this information! Knowing this greatly simplifies the whole 
> find_package stuff...
> 
>>> And is there any documentation on how to create a LibraryConfig.cmake file
>>> with support for components?
>>
>> In KDE we have a macro MACRO_WRITE_BASIC_CMAKE_VERSION_FILE() which helps 
>> with creating a basic version-info file which should be installed along 
>> with the Config-file.
>> It consists of MacroWriteBasicCMakeVersionFile.cmake and 
>> BasicFindPackageVersion.cmake.in which you can find in 
>> http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/ .
> 
> Nice to have some reusable code for versioning...
> 
> About the components question again: I played around a bit, and I think I 
> now more or less have comprehended this. I guess for a package XXX with 
> components YYY and ZZZ, one could set variables XXX_HAS_YYY and XXX_HAS_ZZZ
> and then use a loop like this one in the XXXConfig.cmake file:
> 
> foreach( component ${XXX_FIND_COMPONENTS} )
> if ( XXX_HAS_${component})
> set ( XXX_${component}_FOUND TRUE )
> else( XXX_HAS_${component})
> if ( ${XXX_FIND_REQUIRED})
> message(FATAL_ERROR "Required component ${component} not found!")
> elseif ( NOT XXX_FIND_QUIETLY)
> message(STATUS "Component ${component} not found!")
> endif ( ${XXX_FIND_REQUIRED})
> endif ( XXX_HAS_${component})
> endforeach( component )
> 
> Correct?

While that's a possible approach it lacks the invocation-specific
variables, i.e. XXX_{INCLUDE_DIRS,LIBRARIES,DEFINITIONS}, and in
some cases, these can't be assembled in a simple component-wise
manner, see below. Moreover, there are further questions w.r.t.
multi-component packages and their config files:

- Does the config file provide the component-specific variables like
XXX_YYY_FOUND for each available component or for the requested ones
only, i.e. can you rely on XXX_ZZZ_FOUND to have a definite value if
you just said FIND_PACKAGE(XXX COMPONENTS YYY)? With your foregoing
approach, you can't. That's alright, but should be mentioned in the
package's documentation. Imagine the following scenario: There's one
installation of XXX for the native system and another one for cross
compiling purposes. The latter has YYY and ZZZ while the former has
YYY only. Due to FIND_PACKAGE()'s ability to search for config files
in various locations, such a coexistence is easily possible. Now, a
FIND_PACKAGE(XXX COMPONENTS YYY ZZZ) for the cross compilation XXX
returns with XXX_ZZZ_FOUND=TRUE, but does a subsequent invocation of
FIND_PACKAGE(XXX COMPONENTS YYY) within the same scope for the native
XXX return with XXX_ZZZ_FOUND=FALSE, or does XXX_ZZZ_FOUND=TRUE still
hold from the previous invocation? Both alternatives are fine, but the
user should know the score. Besides, it's a good style to refer to any
component-related variables only if the particular component has been
requested explicitly.

- Handling of inter-component dependencies: Imagine the user just says
FIND_PACKAGE(XXX COMPONENTS ZZZ), but ZZZ needs YYY. If YYY is to be
enabled automatically the config file must know about the dependency
and cannot simply add the ZZZ-specific variables to the invocation-
specific ones; the YYY-specific variables must be mentioned, too.

- Do multiple consecutive FIND_PACKAGE(XXX ...) invocations act in an
accumulative manner on the invocation-specific variables? E.g., does

FIND_PACKAGE(XXX COMPONENTS YYY)
FIND_PACKAGE(XXX COMPONENTS ZZZ)

result in XXX_LIBRARIES="${XXX_YYY_LIBRARY} ${XXX_ZZZ_LIBRARY}", or
does the second invocation overwrite the results of the first? Again,
both alternatives are fine, but should be documented. That's important
when there are required and optional components to handle: Imagine YYY
is required while ZZZ is optional for the user; one might tend to say

FIND_PACKAGE(XXX REQUIRED YYY)
FIND_PACKAGE(XXX COMPONENTS ZZZ)

instead of

FIND_PACKAGE(XXX COMPONENTS YYY ZZZ)
IF(NOT XXX_YYY_FOUND)
MESSAGE(FATAL_ERROR ...)
ENDIF()

When turning towards find modules, the situation becomes even more
complicated. From a user's perspective, find modules and config files
should behave the same, but the formers can't know which components are
available, so they must look for them; this gives rise to questions like:

- Meaning of the REQUIRED and QUIET options: When a find module looks
for any component the effects of REQUIRED and QUIET depend on whether
the component has been requested explicitly or not. If it hasn't, the
find m

Re: [CMake] howto re-run file(COPY signature ?

[Michael Hertling]

On 11/24/2010 04:44 AM, Dominique Belhachemi wrote:
> Hello,
> 
> I am using the following command in my CMakeLists.txt file to copy a
> directory with all sub-directories from the source tree to a directory
> in the binary tree.
> 
> file(COPY ${SRCDIR}
>   DESTINATION ${CMAKE_BINARY_DIR}/${DSTDIR}/
>   PATTERN .svn EXCLUDE
> )
> 
> After adding this line to CMakeLists.txt and typing 'make' the command
> is working like expected. But after adding a new file to ${SRCDIR} and
> typing 'make' again, the new file doesn't get copied. I have to do a
> 'touch CMakeLists.txt' first.
> 
> Is there a way to enforce the execution?

You might outsource the FILE(COPY ...) command to a CMake script which
is invoked by a custom target, e.g. as in the following CMakeLists.txt:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(COPYTREE NONE)
ADD_CUSTOM_TARGET(copytree ALL
${CMAKE_COMMAND}
-DSRC=${CMAKE_SOURCE_DIR}
-DDST=/tmp/${PROJECT_NAME}
-P ${CMAKE_SOURCE_DIR}/copytree.cmake
)

The ${CMAKE_SOURCE_DIR}/copytree.cmake script simply looks like:

FILE(COPY ${SRC} DESTINATION ${DST} PATTERN .svn EXCLUDE)

Because FILE(COPY ...) copies files and directories only if they are new
or have been touched you can probably afford the script's execution each
time you build; use ADD_DEPENDENCIES() to ensure that the script runs at
the right time.

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] option, configure_file and ON/OFF

[Michael Hertling]

On 11/23/2010 10:30 PM, Anton Deguet wrote:
> Hello,
> 
> I am trying to use a UI option to set a value used in configure_file and 
> ideally obtain a file that doesn't use ON/OFF.   Here is a CMake sample:
>   option (MYLIB_HAS_WHATEVER "Use whatever library" OFF)
> 
> In my config.h.in I have:
>   #define ON 1
>   #define OFF 0
>   #define MYLIB_HAS_WHATEVER ${MYLIB_HAS_WHATEVER}
> 
> Then in my code I can use:
>   #if MYLIB_HAS_WHATEVER
>   
>   #endif
> 
> It worked so far but there is an issue if we end up using other libraries 
> which also define ON and/or OFF.  There seems to be no way to tell CMake to 
> use 1/0 instead of ON/OFF during the configure_file.  My solution has been to 
> modify my CMake to do the following:
>   option (MYLIB_HAS_WHATEVER "Use whatever library" OFF)
>   if (MYLIB_HAS_WHATEVER)
> set(MYLIB_CONFIG_HAS_WHATEVER 1)
> 
>   else (MYLIB_HAS_WHATEVER)
> set(MYLIB_CONFIG_HAS_WHATEVER 0)
> 
>   endif (MYLIB_HAS_WHATEVER)
> 
> and in the config.h.in do:
>   #define MYLIB_HAS_WHATEVER ${MYLIB_CONFIG_HAS_WHATEVER}
> 
> Is there a better way?

In your config.h.in, simply write:

#cmakedefine01 MYLIB_HAS_WHATEVER

With CONFIGURE_FILE(), this expands to

#define MYLIB_HAS_WHATEVER 0

or

#define MYLIB_HAS_WHATEVER 1

depending on the value of MYLIB_HAS_WHATEVER.

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] an akward preprocessor

[Michael Hertling]

On 11/22/2010 10:39 PM, luxInteg wrote:
> Greetings
> I am learning cmake
> 
> I have a small project to be installed in some directory $INSTALLED 
> =/whatever/installed/directory/is
> 
> 
> I have some files say  fila1.c ..File2.c  to compile   with a preprocessor 
> that includes a reference to  $INSTALL
> how do I set  the compile properties of files with this?
> 
> do I do :- 
> -DWITH_INSTALL_DIR or 
> -Dwhatever_installed_directory_is (i.e. for example -D/usr/local)  
> or ?

Consider ADD_DEFINITIONS(-DWITH_INSTALL_DIR=...); alternatively, you
might add "WITH_INSTALL_DIR=..." to the COMPILE_DEFINITIONS target/
directory/source properties.

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 and no make

[Michael Hertling]

On 11/23/2010 03:25 AM, luxInteg wrote:
> Greetings
> 
> 
> I am learning cmake
> 
> 
> Compiling alglib (http://www.alglib.net/) (cpp)  does not use make
> It is done simply by a command such as 
>  g++  -c *.cpp in the src directory
> 
> QUESTION.  If one wants a library from alglib  I would like to know if it can 
> it be compiled  using  CMAKE  and if so how so

Set up a src/CMakeLists.txt, a tests/CMakeLists.txt and a top-level
CMakeLists.txt, use ADD_LIBRARY(), ADD_EXECUTABLE(), ADD_TEST() and
ADD_SUBDIRECTORY() along with the usual CMake stuff, and consider
to offer the finished CMakeLists.txt files to the alglib folks.

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] providing library information, what's the cmake way

[Michael Hertling]

On 11/22/2010 11:28 PM, Ian Monroe wrote:
> So with a library, the correct thing to do is to install your
> FindLibrary.cmake into ${CMAKE_ROOT}/Modules and then dependent
> projects would just do find_package(Library REQUIRED) correct?

If the library is built with CMake it should provide a configuration
file LibraryConfig.cmake or library-config.cmake and install it to a
proper location, e.g. /(share|lib) on *nix. Hence, you don't
need to write to ${CMAKE_ROOT}/Modules, and FIND_PACKAGE() looks for
a configuration file by a more sophisticated procedure as for a find
module. Usually, the latters are meant for non CMake-aware packages.

> I guess I'm thinking about how, in the situation where they don't have
> the library installed, they would then just get a cmake error that it
> can't find the FindLibrary.cmake. So that doesn't really seem right.

It's the REQUIRED flag which throws the fatal error if neither a find
module nor a configuration file is found. Dropping this flag, you might
refer to the Library_FOUND variable set explicitly by FindLibrary.cmake
or automatically by FIND_PACKAGE() according to whether a configuration
file has been found or not:

FIND_PACKAGE(Library)
IF(NOT Library_FOUND)
# Handle Library's absence.
ENDIF()

> We're going from SVN to Git and splitting up a monolithic project
> (kdebindings) into several separate projects (qtruby, korundum,
> smoke...). I really don't want to have a copy of FindLibrary.cmake
> (well really FindSmoke.cmake) in each project's repo.

IMO, it's sufficient to have a SmokeConfig.cmake in smoke's repository
and install it along with smoke's other stuff. Later on, you refer to
smoke like mentioned above, or with the REQUIRED flag if you cannot
proceeed without smoke being found.

> This seems like a common situation,  so I'm wondering what the common
> solution is.

'hope that helps.

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] Creating a XXXConfigYYY.cmake file

[Michael Hertling]

On 11/17/2010 04:13 PM, Torri, Stephen CIV NSWCDD, W15 wrote:
> I have been reading email posts on goggle that says if you create a library 
> then produce a Configcmake file rather than a Find.cmake 
> file. That is fine but what confuses me is:

Indeed, a package XXX - particularly a library - that's intended to
be used by a CMake-aware project should provide a configuration file
XXXConfig.cmake or xxx-config.cmake to expose the necessary information
for its usage. Nevertheless, the version file XXXConfigVersion.cmake or
xxx-config-version.cmake is meant as a companion of the configuration
file and tests whether the package provides a suitable version w.r.t.
the one requested by the user via FIND_PACKAGE()'s version parameter.

> 1. What do I put in it? 

For the library XXX, e.g., XXXConfig.cmake should provide the same as a
FindYYY.cmake module for a non CMake-aware package YYY, i.e. at least:

XXX_LIBRARY: Path of the installed libXXX.{so,a}
XXX_INCLUDE_DIR: Directory of the installed XXX.h
XXX_DEFINITIONS: Definitions necessary to use XXX.h
XXX_LIBRARIES: XXX_LIBRARY and all prerequisite libraries
XXX_INCLUDE_DIRS: XXX_INCLUDE_DIR and all prerequisite directories

The remaining XXX_FOUND variable is set to TRUE automatically if
FIND_PACKAGE() finds the configuration file, in contrast to the find
module which could set YYY_FOUND to FALSE. See [1] for more information.

> 2. How do I install it? (e.g. Linux and Windows)

Of course, it should be installed at a location which is searched by
FIND_PACKAGE(), see FIND_PACKAGE()'s documentation. On *nix, e.g., the
/(share|lib) locations are the suitable ones. The configuration
file's installation itself can be done as usual by an INSTALL(FILES ...).

> 3. What google search terms should I use to find more information on this 
> topic?

See [1] and [2] for the basics, and [3] for a related discussion.

> I have a large project is broken up into three separate projects each with 
> their own CMakeLists.txt. For the sake of discussion lets call them Larry, 
> Curly and Mo. Now Larry is the base library. Supposing I knew what I was 
> doing I would create a LarryConfig1.0.cmake file and install it. I would do 
> the same for the others. Do I just use find_package in the CMakeLists.txt of 
> Curly and Mo to find the Larry library?

IMO, this depends on the degree of interconnection among Larry, Curly
and Mo. If each of them is useful on its own they could be considered
as independent such that there're {Larry,Curly,Mo}Config.cmake files,
and the latters use FIND_PACKAGE(Larry) to look for the base library.
If Larry, Curly and Mo are strongly interconnected, particularly if
they're always installed together, they could be considered as parts
of a superior project such that there's a sole Config.cmake
file which knows their installation locations and provides variables
like, e.g., _Larry_LIBRARY, _Curly_EXECUTABLE and
_Mo_FOUND. If some of these parts, e.g. Curly and Mo, don't
need to be installed along with Larry each time you might process the
_FIND_COMPONENTS variable provided by FIND_PACKAGE() for the
Config.cmake in order to let the user select or deselect them.

> Is there a tutorial on how to do this? One full example (e.g. create config 
> file, installing config file, using config file) would be sufficient to help 
> me. Right now I can build the large project fine on Linux but on Windows I am 
> having trouble of telling Curly where Larry is installed.

For a simple library project XXX, I'd use a template XXXConfig.cmake.in:

FIND_LIBRARY(XXX_LIBRARY XXX
PATHS @CMAKE_INSTALL_PREFIX@/lib
NO_DEFAULT_PATH
)
SET(XXX_LIBRARIES ${XXX_LIBRARY})
FIND_PATH(XXX_INCLUDE_DIR XXX.h
PATHS @CMAKE_INSTALL_PREFIX@/include
NO_DEFAULT_PATH
)
SET(XXX_INCLUDE_DIRS ${XXX_INCLUDE_DIR})
SET(XXX_DEFINITIONS ...)
# XXX_FOUND is set to "1" by FIND_PACKAGE().

This expects the library to be installed in ${CMAKE_INSTALL_PREFIX}/lib
and the headers to be installed in ${CMAKE_INSTALL_PREFIX}/include. Use
CONFIGULE_FILE() on the template to generate the actual XXXConfig.cmake,
and INSTALL(FILES ...) for the latter's installation as mentioned above.
Finally, after a FIND_PACKAGE(XXX) in another project's CMakeLists.txt,
you can access those variables to use XXX's headers and link against
its library.

Regards,

Michael

[1] ${CMAKE_ROOT}/Modules/readme.txt
[2] http://www.cmake.org/Wiki/CMake_2.6_Notes#Packages
[3] http://www.mail-archive.com/cmake@cmake.org/msg28425.html
___
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] so lib symlinks

[Michael Hertling]

On 11/19/2010 02:35 PM, luxInteg wrote:
> Greetings,
> 
> I am learning cmake.  I practice using the   "add_library comand" as shown 
> below
> 
> 
> set(serial "1.2.3")
> add_library(testLIB SHARED testLIB.c)
> set_target_properties(testLIB PROPERTIES VERSION ${serial} SOVERSION 1)
> SET(CMAKE_INSTALL_LIBDIR lib CACHE PATH "Output directory for libraries")
> 
> the result is  in the ~/lib directory after install is the following:-
> 
> -A
> libtestLIB.so   a symbolic-link  to  libtestLIB.so.1 
> libtestLIB.so.1   a symbolic-link  to  libtestLIB.so.1.2.3
> 
> 
> which I think is the proper way according to this link. 
> (  http://www.faqs.org/docs/Linux-HOWTO/Program-Library-HOWTO.html ). 
>  However it seems some programs do not  follow the symlinks  as I had unable 
> to open 
> libtestLIB.so.1 in one instance.. [...]

What do you mean with "unable to open libtestLIB.so.1 in one instance"?
What happened exactly? Which messages do you get from which programs?

> [...] It is probably   the rest of the libraries 
> on  my setup has are like so:-
> 
> ---B
> libtestLIB.so   a symbolic-link  to  libtestLIB.so.1.2.3 
> libtestLIB.so.1   a symbolic-link  to  libtestLIB.so.1.2.3
> 
> 
> So advice would be appreciated on how  one  uses  set_target_properties  or 
> shared libraies to get  a setup as in ---B---.

Usually, it doesn't matter if the .so is linked to the soname'd library
- a link itself, also created by ldconfig - or the actual library file.

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] selecting correct g++/libstdc++.so pair

[Michael Hertling]

On 11/18/2010 11:01 PM, Russell L. Carter wrote:
> Hi all,
> I have three g++ versions installed.  Debian's native g++-4.3 and
> g++-4.4 both use /usr/lib/libstdc++.so.6.13, while
> /usr/local/bin/g++-4.5 needs /usr/local/lib64/libstdc++.so.6.14.
> 
> If I use CXX=/usr/local/bin/g++-4.5 at configure time, executables
> are linked against /usr/lib/libstdc++.so.6.13, which is not what
> I want.  What is the approved Cmake Way for insuring that executables
> using g++-4.5 link against libstdc++.so.6.14?

The selection of libstdc++ takes place by the usual library searching
mechanism, so you must ensure that /usr/local/lib64/libstdc++.so.6.14
takes precedence over /usr/lib/libstdc++.so.6.13 for runtime linking.
Use ldconfig in connection with /etc/ld.so.conf, the LD_LIBRARY_PATH
environment variable et al., or pass appropriate rpath settings to
the linker, whatever suits your needs best.

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] Howto to work with variables from central makefiles....

[Michael Hertling]

On 11/17/2010 04:56 PM, Thomas Lehmann wrote:
>>> for an automatically forced include I have provided an
>>>
>>> option like this:
>>>
>>>
>>>
>>> set(WIN32_SPEC
>> ${CMAKE_CURRENT_SOURCE_DIR}/../../libs/global/win32_spec.h)
>>
>> May you could use an absolute reference using
>>
>> ${PROJECT_SOURCE_DIR}/libs/global/win32_spec.h
>>
>> if your project is name TOTO
>> (from the PROJECT(TOTO CXX) statement)
>> you use
>>
>> ${TOTO_SOURCE_DIR}/libs/global/win32_spec.h.
> 
> it depends on how I use cmake. I can use the root of all
> sources or I use a subtree.
> Let's say I have following setup.
> 
> /src/libs
> /src/cmake
> /src/apps
> 
> when I call "cmake /src" or "cmake /src/apps" is relating the
> application to be build no difference but the variable CMAKE_SOURCE_DIR
> will change. My central files are in /src/cmake.
> 
> I would like avoiding to redefine search paths and variables in each 
> individual
> makefile depending on its location in the source tree. One example:
> 
> 
> # ensuring that packages are found
> set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
>   ${CMAKE_CURRENT_SOURCE_DIR}/../../scripts/make)
> 
> # most common definitions, macros, ... required by most projects
> find_package(AllOptions)
> 
> 
> I think that the problem is that cmake does not know where the real root
> is. I have not found something except adjusting an environment variable
> but this is something I would like to avoid when possible...

If you don't want to make /src the definite top-level directory of your
project(s) you must indeed provide a hint to /src/cmake since otherwise,
CMake cannot have an idea that there's additional stuff in this sibling,
e.g. "cmake -DCMAKE_CENTRAL_DIR=/src/cmake /src/apps". Alternatively,
you might always configure /src and use options to decide which
projects, i.e. subdirectories, are actually built, e.g.:

/src/CMakeLists.txt:
OPTION(BUILD_LIBS "Build libs" ON)
OPTION(BUILD_APPS "Build apps" ON)
IF(BUILD_LIBS)
ADD_SUBDIRECTORY(libs)
ENDIF()
IF(BUILD_APPS)
ADD_SUBDIRECTORY(apps)
ENDIF()

So, you can say "cmake /src" to build libraries and applications, or
"cmake -DBUILD_APPS=OFF /src" to build libraries only etc., and in
any case, you may refer safely to ${CMAKE_SOURCE_DIR}/cmake from
each of your projects' CMakeLists.txt.

Regards,

Michael

>>> add_definitions(-FI ${WIN32_SPEC})
>>>
>>>
>>> But when including this central file (find_package) the variable
>> CMAKE_CURRENT_SOURCE_DIR
>>> changes and then the path and filename of the header is wrong.
>>>
>>>
>>>
>>> How to proceed best?
>>> Can I avoid that for those "set" statement the variable is not
>> overwritten by those
>>> files including this central makefile?
>>
>> You may use a CACHED variable
>> set(WIN32_SPEC ${PROJECT_SOURCE_DIR}/libs/global/win32_spec.h CACHE
>> FILEPATH "Central Include")
>>
>> the first calling this will set the value then other set will be
>> ignored.
>> If you want to override a CACHE var value you'll have to use FORCE set
>> option.
>>
>>
>>
>> --
>> Erk
>> Membre de l'April - « promouvoir et défendre le logiciel libre » -
>> http://www.april.org
> 
> Thomas Lehmann
> Scrum Master
> 
> RTS Realtime Systems Software GmbH, Rembrandtstrasse 13, D-60596 Frankfurt am 
> Main
> T: +49.69.61009.0 / F: +49.69.61009.181
> 
> Sitz: Frankfurt am Main - HRB 84467 Amtsgericht Frankfurt am Main
> Geschäftsführer: Steffen Gemuenden, Igor Sluga
> 
> www.rtsgroup.net
> 
> This email and any attachments are for the exclusive and confidential use of 
> the intended recipient. If you are not the intended recipient, or an employee 
> or agent responsible for delivering this message to the intended recipient, 
> please do not read, distribute or take action in reliance upon this message. 
> If you have received this in error, please notify me immediately by return 
> email and promptly delete this message and its attachments from your computer 
> system.
___
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] Run compiler through another tool?

[Michael Hertling]

On 11/17/2010 10:37 AM, Hariharan wrote:
> Is it possible to run the compiler and linker through another command, say
> "time" or a custom script? In other words, I want the compile and link steps
> to run " gcc" and " ld".

If you're using a Makefile generator you might have a look at the rule
launchers, i.e. the RULE_LAUNCH_{COMPILE_CUSTOM,LINK} global/target/
directory properties.

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] How to install openbabel python bindings by using the new cmake installer (problem selecting a particular python version).

[Michael Hertling]

On 11/13/2010 03:08 PM, Marcus D. Hanwell wrote:
> On Nov 13, 2010, at 8:57 AM, Michael Hertling wrote:
> 
>> On 11/12/2010 02:13 PM, Hector Martinez-Seara wrote:
>>> Dear all,
>>> I'm trying to install openbabel in linux which in its last version
>>> (2.3.0) uses cmake installer. I haven't been able to compile it with
>>> biddings with python 3.1 when using the -DPYTHON_BINDINGS=ON option. I
>>> have python 2.7 and 3.1 installed in my system and the python command
>>> points to python 3.1. Still cmake only select python 2.7 despite it is
>>> not set as preferred in my system in any way. I have made a small
>>> search and I have seen that there is a lot of troubles selecting
>>> python 3 with cmake. Most of the information was very technical and
>>> honestly I'm not sure if there was any solution at the end.
>>
>> AFAIK, the FindPython{Interp,Libs}.cmake modules are currently not
>> capable to find Python 3, so you should focus on a manual approach
>> at the moment, see below. With the scheduling of issue 8396 for the
>> 2.8.4 roadmap, there's a perpective for the availability of version-
>> or pattern-aware find functions, so maybe, it is possible to improve
>> the find modules w.r.t. version selection in the near or medium term.
> 
> This is certainly something I would like to address before the 2.8.4 release, 
> but as you said there is no Python 3 awareness right now in the find modules. 
> Do the Open Babel Python modules work in Python 3? I work on that project, 
> and was not aware that Python 3 support was there, but do not work much on 
> the bindings.

On occasion of Hector's inquiry, I've just taken a look at Open Babel's
CMakeLists.txt files to see how they could possibly be made not search
for a Python 2 installation, but I don't know if it generally works
with Python 3. Perhaps, Hector can provide some information.

>>> My question is rather easy:
>>> a) Is there any way to force a specific python version (3.1) from the
>>> cmake command line?
>>
>> You might try to set the PYTHON_EXECUTABLE, PYTHON_INCLUDE_DIR and
>> PYTHON_LIBRARY variables to appropriate values for your Python 3.1
>> installation on the command line, i.e. by use of the -D option or
>> -C along with a prepared script. AFAICS, defining these variables
>> makes the FindPython{Interp,Libs}.cmake modules not look for the
>> interpreter, the include directory and the library by themselves,
>> so you possibly get by without any further modifications, but I
>> have not yet tested this with Open Babel.
>>
>>> or b) Is there variable which I could export, e.g. CC=gcc4.5, to force
>>> python to select the python version I want?
>>
>> None I'm aware of, but - as stated above - there're some undertakings
>> in the near future that might result in a comprehensive and flexible
>> FindPython.cmake module which receives the requested version through
>> FIND_PACKAGE()'s version parameter, including version 3.
>>
> That would certainly be the ideal solution.

Yes, absolutely, and I'm hopeful that addressing 8396 will pave the
way for this and related concerns. My vision of the objectives are:

- Instead of just considering FIND_LIBRARY(), one should enhance all
  find functions, i.e. FIND_{LIBRARY,PROGRAM,FILE,PATH}(), as James
  Bigler has proposed in issue 10856. In particular for Python, one
  needs improved FIND_PROGRAM() and FIND_PATH() functions to search
  for the versioned interpreter executables and module directories.
- Instead of implementing support for version selection, one should
  add general regex pattern matching as proposed in 10856, too. IMO,
  pattern matching does suit much better to the find functions than
  version selection, is universally useful on its own and has been
  requested several times before.
- Pattern-aware find functions should just return a list of matching
  candidates whereas the selection of a specific version may be done
  by a function implemented in CMake's scripting language, and this
  function might use the VERSION_EQUAL/VERSION_GREATER/VERSION_LESS/
  VERSION_GREATER_OR_EQUAL/VERSION LESS_OR_EQUAL parameters proposed
  by Philip Lowman for FIND_LIBRARY().
- The enhanced find functions should be used along with that version
  selection function to write a FindPython.cmake which makes use of
  FIND_PACKAGE()'s version specification facility and is capable to
  handle Python 2 and 3 in an equal manner.
- Finally, this advancement should be used to improve certain find
  modules currently containing hardcoded version numbers, e.g. the
  Tcl/Tk ones or FindPNG.cmake. Hence, the FIND_PACKAGE() version
  parameter could be used t

Re: [CMake] ARCHIVE_OUTPUT_DIRECTORY seems to not work

[Michael Hertling]

On 11/16/2010 06:18 PM, Andrea Galeazzi wrote:
> I'm trying to compile a static library named libkernel.a into a custom 
> path. I tried to set ARCHIVE_OUTPUT_DIRECTORY in two ways:
> 1:
> set_property(TARGET PROPERTY ARCHIVE_OUTPUT_DIRECTORY 
> "O:/kernel/${CMAKE_SYSTEM_NAME}/${CMAKE_BUILD_TYPE}")
>  message("library output: ${ARCHIVE_OUTPUT_DIRECTORY}")
> add_library( Kernel STATIC ${SOURCES} )
> 2:
>  set(ARCHIVE_OUTPUT_DIRECTORY 
> "O:/kernel/${CMAKE_SYSTEM_NAME}/${CMAKE_BUILD_TYPE}")
>   message("library output: ${ARCHIVE_OUTPUT_DIRECTORY}")
>   add_library( Kernel STATIC ${SOURCES} )
> 
> but  the file libkernel.a is always created into the build directory. 
> Furthermore in the first case the output of  message("library output: 
> ${ARCHIVE_OUTPUT_DIRECTORY}") is: << library output. >>
> I currently use eclipse CDT - MinGW.
> Maybe I miss something but what?

In 1, you don't specify any targets the property is imposed on; try
SET_PROPERTY(TARGET Kernel PROPERTY ARCHIVE_OUTPUT_DIRECTORY ...) or
SET_TARGET_PROPERTIES(Kernel PROPERTIES ARCHIVE_OUTPUT_DIRECTORY ...)
after the ADD_LIBRARY(Kernel ...). Furthermore, there's no predefined
variable ARCHIVE_OUTPUT_DIRECTORY, thus it turns out to be empty, and
setting this variable in 2 has no effect. Rather, there is a variable
CMAKE_ARCHIVE_OUTPUT_DIRECTORY which initializes the target property
ARCHIVE_OUTPUT_DIRECTORY for all targets, cf. the documentation.

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] postBuildInstallation howto

[Michael Hertling]

On 11/13/2010 08:06 PM, luxInteg wrote:
> Greetings,
> 
> I am learning cmake
> 
> 
> --I want to know how to set   the installation directory tree.  Is this done 
> in the CMakeList.txt in the base directory; if not where and how?

IIRC, the INSTALL() command with the FILES, PROGRAMS and DIRECTORY
signature may appear in any CMakeLists.txt, but with the TARGETS
signature, it must be placed in the same CMakeLists.txt as the
targets it refers to. Anyway, IMO, it's a good style to have
the INSTALL() commands near their subjects, generally.

> --I want to install   man pages, TEX files etc, I checked this 
> http://www.cmake.org/Wiki/CMake:Install_Commands   but did not see any 
> references to files of the latter types -So how are these installed  from a 
> ~/doc directory in the build tree?

E.g., in the source directory's ~/doc/CMakeLists.txt, say

INSTALL(FILES ${MANPAGES} DESTINATION man)

with the variable MANPAGES containing the to-be-installed man pages
with their absolute paths within the build directory, or preferably

INSTALL(DIRECTORY ${CMAKE_BINARY_DIR}/doc/man/ DESTINATION man)

to install the contents of ${CMAKE_BINARY_DIR}/doc/man to the
${CMAKE_INSTALL_PREFIX}/man directory; note the trailing slash.

BTW, don't use the old INSTALL_{FILES,PROGRAMS,TARGETS}() commands; use
the new comprehensive INSTALL() command with its signatures exclusively.

> --If say one has a directory named INCLUDE in the build tree and one sets  
> the 
> files therein as ${headers}  does one  do 
> INSTALL_FILES(/include ${headers}) to install into ${Install_prefix}/include 

If the headers variable contains absolute paths, you might say
INCLUDE(FILES ${headers} DESTINATION include) anywhere the headers
variable is defined to install to the ${CMAKE_INSTALL_PREFIX}/include
directory. Otherwise, you should say INCLUDE(DIRECTORY / DESTINATION include) to install the contents of the whole
INCLUDE directory to ${CMAKE_INSTALL_PREFIX}/include - preferable again.

> and is it done from a CMakeLists.txt within ~/INCLUDE to 
> effect installation OR do you do otherwise and if so how so?

You said the INCLUDE directory is in the build tree, and the build tree
has no CMakeLists.txt unless you're doing a discouraged in-source build:



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] How to install openbabel python bindings by using the new cmake installer (problem selecting a particular python version).

[Michael Hertling]

On 11/12/2010 02:13 PM, Hector Martinez-Seara wrote:
> Dear all,
> I'm trying to install openbabel in linux which in its last version
> (2.3.0) uses cmake installer. I haven't been able to compile it with
> biddings with python 3.1 when using the -DPYTHON_BINDINGS=ON option. I
> have python 2.7 and 3.1 installed in my system and the python command
> points to python 3.1. Still cmake only select python 2.7 despite it is
> not set as preferred in my system in any way. I have made a small
> search and I have seen that there is a lot of troubles selecting
> python 3 with cmake. Most of the information was very technical and
> honestly I'm not sure if there was any solution at the end.

AFAIK, the FindPython{Interp,Libs}.cmake modules are currently not
capable to find Python 3, so you should focus on a manual approach
at the moment, see below. With the scheduling of issue 8396 for the
2.8.4 roadmap, there's a perpective for the availability of version-
or pattern-aware find functions, so maybe, it is possible to improve
the find modules w.r.t. version selection in the near or medium term.

> My question is rather easy:
> a) Is there any way to force a specific python version (3.1) from the
> cmake command line?

You might try to set the PYTHON_EXECUTABLE, PYTHON_INCLUDE_DIR and
PYTHON_LIBRARY variables to appropriate values for your Python 3.1
installation on the command line, i.e. by use of the -D option or
-C along with a prepared script. AFAICS, defining these variables
makes the FindPython{Interp,Libs}.cmake modules not look for the
interpreter, the include directory and the library by themselves,
so you possibly get by without any further modifications, but I
have not yet tested this with Open Babel.

> or b) Is there variable which I could export, e.g. CC=gcc4.5, to force
> python to select the python version I want?

None I'm aware of, but - as stated above - there're some undertakings
in the near future that might result in a comprehensive and flexible
FindPython.cmake module which receives the requested version through
FIND_PACKAGE()'s version parameter, including version 3.

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] making executible in mixed C/fortran project

[Michael Hertling]

On 11/12/2010 05:37 PM, luxInteg wrote:
> On Friday 12 November 2010 13:17:50 Michael Hertling wrote:
>> On 11/12/2010 02:46 PM, luxInteg wrote:
>>> Greetings,
>>>
>>> I am learning cmake
>>>
>>> I am building an executable  which needs to   first compile a C program 
>>> and then recompiling the object file   with another file in fortran.
>>>
>>>
>>> Here is  an excerpt from a unix makefile I am attempt to port to cmake as
>>> part of my cmake turotial.
>>>
>>> fileC.o: fileC.c
>>>
>>> $(C) -DDINT -c fileC.c
>>>
>>> fileD:  fileD.f fileC.o ../lib/libF.a
>>>
>>> $(F77) $(F77FLAGS) -o fileD fileD.f fileC.o../lib/libF.a $(F77LIB)
>>>
>>> I  think I have learnt enough cmake to do most of the above  EXCEPT I am
>>> unsure how on compile an object file  (in this case  fileC.o
>>> with a fortran compiler (if I have translated the makefile correctly)
>>>
>>>  Does one  rename   the file or whatever?
>>>
>>> Guidance on how to do this would be appreciated
>>
>> You might try
>>
>> ADD_LIBRARY(C STATIC fileC.c)
>>
>> in junction with
>>
>> TARGET_LINK_LIBRARIES(fileD C ...)
> 
> 
> It would not go in the loop 
> 
> add_executable(fileD
> fileD.f 
> ADD_LIBRARY(fileC STATIC fileC.c )
> ${fileC}  )

Which loop are you talking about, and which value does the "fileC"
variable has here? Moreover, the ADD_LIBRARY() command must not
appear among the source files of ADD_EXECUTABLE(), of course.

> so I tried  it outside like so:-
> 
> SET_SOURCE_FILES_PROPERTIES( fileC.c  PROPERTIES  COMPILE_DEFINITIONS DINT )
> ADD_LIBRARY(fileC STATIC fileC.c )
> add_executable(fileD
> fileD.f 
> ${fileC}  )
> 
> target_link_libraries(fileD   $(F77LIB) )

That's better, but you need to mention the fileC library target in
TARGET_LINK_LIBRARIES() for this to work, and again: What's the value
of the "fileC" variable here? Note that you've an equally named target.

If you don't really intent to re-use fileC.c, but just want to mix it
with the Fortran sources of fileD, you can do so, i.e. you might say

ADD_EXECUTABLE(fileD fileD.f fileC.c)

but when mixing several languages read about the LINKER_LANGUAGE
target property as well as the CMAKE__LINKER_PREFERENCE
and CMAKE__LINKER_PREFERENCE_PROPAGATES variables.

> ---but  make ends like so:-
> CMakeFiles/filedD.dir/filedD.f.o: In function `MAIN__':
> filedD.f:(.text+0x2f9): undefined reference to `Ddefaults_'
> filedD.f:(.text+0x32b): undefined reference to `Dorder_'
> filedD.f:(.text+0x33a): undefined reference to `Dinfo_'
> collect2: ld returned 1 exit status

Usually, that means there are missing sources in ADD_EXECUTABLE() or
missing libraries in TARGET_LINK_LIBRARIES(); perhaps, you can post
a complete but minimal example as a demonstration of this issue.

> oher suggestions welcomed
>> since you shouldn't directly refer to object files with CMake.

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] un circle dependency

[Michael Hertling]

On 11/12/2010 02:47 PM, luxInteg wrote:
> On Thursday 11 November 2010 21:55:31 Alexander Neundorf wrote:
>> On Thursday 11 November 2010, luxInteg wrote:
>>> Greetings
>>>
>>> I am learning cmake.
>>>
>>>   I think I now know how to generate libraries and executables but  I
>>>   have
>>>
>>> not yet grasped  how  the tree and   directory structure is handled and
>>> by conseqence how one navigates therein.
>>>
>>>
>>> I have this problem.  Lets say my   build tree has these directories
>>>
>>> L---$originalSourceTree/build/lib
>>> M---$originalSourceTree/build/bin
>>>
>>> libraries   say libA.so libB.a are in L.  I want to generate  
>>> executables A.bin and B.bin in M but
>>> they each need  to link to  newly generated  libraries  libA.so libB.a
>>>
>>>
>>> a) how do I direct cmake  (in the CMakeLists.txt/base directory) to build
>>> the libraries in ( L )above   first  -i.e. before atempting to do finds
>>> of nonexistant libraries  ?
>>
>> The add_library() commands must be before the add_executable() commands,
>> otherwise the libraries "A" and "B" are not yet know when you do
>> target_link_libraries(exe A B)
>>
>> Beside that, the dependencies in the generated makefiles are complete, so
>> whenever you do a build, cmake makes sure that the libraries are up-to-date
>> before it builds the executable.
>>
>>> b) if I   insert lines such 'find_library(LIB  libA  path ../lib'   in
>>> the CmakeLists.txt in the base directory  this  results in an error  so
>>> what does one insert?
>>
>> find_library() is not necessary, you can simply use the names of the
>> library targets when linking against them.
> 
> thanks  for the help,
> 
> I added 
> 
> ADD_DEPENDENCIES(libA  ../path/to/A_exec )
> 
> to the CMakeLists.txt in  ~/lib directory (i.e.L)

Besides the fact that this line would establish a dependency *of* libA
*on* A_exec - from your initial post, I cannot see such a necessity -
it actually does nothing as "../path/to/A_exec" is no logical target
in your project, I suppose, but ADD_DEPENDENCIES() operates on such
targets only. BTW, are you sure you have a circular dependency, i.e.
A_exec depends on libA depends on A_exec?

> ---AND
> add_executable(A.exec fileA.c)
> target_link_libraries(A.exec  libA )
> 
> to the CMakeLists.txt  in the ~/bin directory (i.e.M) a
> 
> and it seems to have worked

The TARGET_LINK_LIBRARIES() is absolutely right and also sufficient, IMO.

> -A   related problem is   described below
> 
> I have this  file:- (orig_A_exec.out) in in the ~/bin (of the source tree)
> after building A_exec  as explained above   I tried running the shall command 
> below
> 
> EXECUTE_PROCESS(COMMAND ./A_exec > new_A_exec.out  
> - diff orig_A_exec.out   new_A_exec.out )
> 
> but I did not see  neither new_A_exec.out  nor orig_A_exec.out in ~/bin 
> in 
> the build directory (i.e.M) i.e nothing happened.
> 
> 
> I am using a bash  shell.  some guidance on how to execute bash  commands in 
> cmake  would be appreciated.

EXECUTE_PROCESS() is run at configuration time, i.e. when CMake runs,
but at that time, your A_exec hasn't been built, yet, or stems from a
previous build in which case it is outdated, so you don't want to run
it in order to check its output. If you want to run an executable after
it has been built use ADD_CUSTOM_COMMAND(TARGET ...) or ADD_TEST() with
"make test" or CTest as suggested recently for your BouncyBall example.

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] making executible in mixed C/fortran project

[Michael Hertling]

On 11/12/2010 02:46 PM, luxInteg wrote:
> Greetings,
> 
> I am learning cmake
> 
> I am building an executable  which needs to   first compile a C program  and 
> then recompiling the object file   with another file in fortran.
> 
> 
> Here is  an excerpt from a unix makefile I am attempt to port to cmake as 
> part 
> of my cmake turotial.
> 
> fileC.o: fileC.c
>   $(C) -DDINT -c fileC.c
> 
> fileD:  fileD.f fileC.o ../lib/libF.a
>   $(F77) $(F77FLAGS) -o fileD fileD.f fileC.o../lib/libF.a $(F77LIB)
> 
> 
> 
> I  think I have learnt enough cmake to do most of the above  EXCEPT I am 
> unsure how on compile an object file  (in this case  fileC.o
> with a fortran compiler (if I have translated the makefile correctly)
>  Does one  rename   the file or whatever?
> Guidance on how to do this would be appreciated

You might try

ADD_LIBRARY(C STATIC fileC.c)

in junction with

TARGET_LINK_LIBRARIES(fileD C ...)

since you shouldn't directly refer to object files with CMake.

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] building static binaries

[Michael Hertling]

On 11/03/2010 10:36 PM, Szilárd Páll wrote:
> Hi,
> 
> First of all, I'd be grateful for a reply to the 2nd of my question.
> Can anyone confirm that LINK_SEARCH_END_STATIC on Linux + gcc is
> buggy?

Indeed, I can confirm that enabling the LINK_SEARCH_END_STATIC target
property without further measures results in "cannot find -lgcc_s" on
my Linux with GCC. Additionally including "-static" in the LINK_FLAGS
succeeds, but prevents linking against shared libraries at all, and I
doubt if this is the intention of the LINK_SEARCH_END_STATIC property.

Perhaps an issue with GCC?

Regards,

Michael

> @Michael: Thanks for the link, I've actually seen that thread, but I
> was quite disappointed by the conclusions so I asked with the hope
> that the opinion of the developers has shifted.
> 
> I have only one thing to add to the static/shared library finding
> business. Although I understand that the Win community is large enough
> to invalidate certain CMake feature requests that do not favor this
> OS, but IMHO in this case it would be fairly straightforward to
> implement this feature for at least a dozen *NIX OS-es. In particular,
> I like the suggestion that Philip Lowman suggested
> (http://www.mail-archive.com/cmake@cmake.org/msg21354.html).
> 
> --
> Szilárd
> 
> 
> 
> On Wed, Nov 3, 2010 at 5:57 PM, Michael Hertling  wrote:
>> On 11/02/2010 10:54 PM, Szilárd Páll wrote:
>>> Hi,
>>>
>>> I've been trying to implement a feature which would enable building
>>> static binaries with cmake, but I've got completely stuck, I hope
>>> someone can hint me what's the best way to do this.
>>>
>>> What I've done is a 2 stage solution for making static binaries:
>>>
>>> 1) Telling cmake to prefer picking up ".a"-s when searching for
>>> libraries (CMAKE_FIND_LIBRARY_SUFFIXES).
>>>
>>> This works fine, but referring to file extensions/endings might not be
>>> general enough. Making it less platform-dependent would require
>>> rewriting the way external libraries are treated: instead of adding
>>> them with full path we'd need to add -Lpath -llibname separately. Any
>>> other ways for doing this?
>>>
>>>
>>> 2) Telling cmake to use static system libraries.
>>>
>>> This should work with the target property LINK_SEARCH_END_STATIC which
>>> essentially should result in a the system libs linked in statically
>>> whenever possible (depending on the platform). Well, it seems that
>>> even in fairly straightforward situations (Linux + gcc) I get the a
>>> linker error: /usr/bin/ld: cannot find -lgcc_s.
>>>
>>> Obviously, libgcc_s.a is not available, but by looking at the verbose
>>> output, the implicit gcc linker call contains the "-Wl,-Bstatic"
>>> argument. This AFAIK is not correct, or more precisely not enough to
>>> just tell ld to link statically, gcc also has to know about it
>>> (through the "-static" argument). Can anyone confirm this?
>>>
>>>
>>> I'd be grateful for tips on how to fix the issue with 2), but I'm open
>>> for other portable (and preferably elegant) solutions.
>>
>> FYI: See [1], and in particular [2] and [3].
>>
>> Regards,
>>
>> Michael
>>
>> [1] http://www.mail-archive.com/cmake@cmake.org/msg21106.html
>> [2] http://www.mail-archive.com/cmake@cmake.org/msg21317.html
>> [3] http://www.mail-archive.com/cmake@cmake.org/msg21416.html
___
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] object file questuon

[Michael Hertling]

On 11/11/2010 01:52 PM, luxInteg wrote:
> I am learning cmake
> 
> (in gnu Makefiles it is possible to specifiy the name of the object file. )
> 
> I.E.   if I have a  file   file1.c and I want to  generate two object files
> file1.o  and file1a.o   
> 
> -is this possible in cmake  and if so how so?

FYI: 

Copy file1.c to file1a.c or link file1a.c to file1.c, respectively, and
proceed as usual, but first of all, think about Michael W.'s question.

Regards,

Michael H.
___
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] header files with visual studio

[Michael Hertling]

On 11/10/2010 12:30 AM, Oliver kfsone Smith wrote:
> Michael Hertling said the following on 11/6/2010 7:39 AM:
>> stored in the ${CMAKE_BINARY_DIR}/filelist.dat script as an assignment
>> to the variable FILELIST. Subsequently, this filelist.dat is read via
>> INCLUDE(), so CMake keeps track of it, i.e. changing the filelist.dat
>> results in a rebuild. Finally, the filelist custom target regenerates
>> filelist.dat by executing filelist.cmake. Hence, each time the set of
>> *.c files in CMAKE_SOURCE_DIR changes, a "make filelist" will update
>> filelist.dat, and the following "make" will rebuild - taking into
>> account the refreshed list of source files. Maybe, this approach
>> can be adapted to platforms other than *nix and large projects.
> I already have the source files split up into their myriad sub-projects, 
> all I really want is to tap into the dependency generator to get a list 
> of header files pertinent to any given project.

AFAIK, CMake's built-in dependency scanner offers no interface to hook
in, but possibly, you might use an external tool to achieve your goal:

# ${CMAKE_SOURCE_DIR}/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(HEADERS C)
IF(NOT EXISTS ${CMAKE_BINARY_DIR}/main.headers)
EXECUTE_PROCESS(
COMMAND ${CMAKE_COMMAND}
-DSOURCE=${CMAKE_SOURCE_DIR}/main.c
-DOUTPUT=${CMAKE_BINARY_DIR}/main.headers
-DVARIABLE=HEADERS
-P ${CMAKE_SOURCE_DIR}/headers.cmake
)
ENDIF()
INCLUDE(${CMAKE_BINARY_DIR}/main.headers)
MESSAGE("HEADERS: ${HEADERS}")
ADD_EXECUTABLE(main main.c ${HEADERS})
ADD_CUSTOM_TARGET(headers
COMMAND ${CMAKE_COMMAND}
-DSOURCE=${CMAKE_SOURCE_DIR}/main.c
-DOUTPUT=${CMAKE_BINARY_DIR}/main.headers
-DVARIABLE=HEADERS
-P ${CMAKE_SOURCE_DIR}/headers.cmake
)

# ${CMAKE_SOUIRCE_DIR}/headers.cmake:
EXECUTE_PROCESS(COMMAND gcc -MM ${SOURCE} OUTPUT_VARIABLE HEADERS)
STRING(REGEX REPLACE "^.*: ${SOURCE}" "" HEADERS "${HEADERS}")
STRING(REGEX REPLACE " \n " "\n" HEADERS "${HEADERS}")
FILE(WRITE ${OUTPUT}.in "SET(${VARIABLE}\n${HEADERS})\n")
CONFIGURE_FILE(${OUTPUT}.in ${OUTPUT} COPYONLY)

This is the same approach as in my previous example with the exception
of the filelist.cmake script replaced by headers.cmake. The latter one
makes use of gcc's -MM option to scan a source file's included headers
and writes the list to a file in the form of a SET() command. In turn,
the file is included in CMakeLists.txt to define the HEADERS variable
mentioned in the "main" target's sources. Initially, the headers are
scanned by an explicit invocation of headers.cmake, and after having
added/removed/renamed a header, triggering the "headers" target does
that job, so a subsequent build will reconfigure at first due to the
updated include file. In addition, CONFIGURE_FILE() in headers.cmake
ensures the include file isn't touched if nothing has changed, hence
the headers target doesn't cause unnecessary rebuilds.

This approach can be seen to work on *nix, but it might be possible
to adapt for other platforms and to enhance for extensive projects:

1. Make header.cmake operate on a list of source files.
2. Provide each of the sub-projects with its own headers target.
3. Provide the top-level project with a headers targets and set up
   dependencies of the latter on the sub-projects' ones, so building
   the top-level headers target will update the header file lists of
   the entire project resulting in reconfiguration and maybe rebuild.

Clearly, the downside is the usage of an external dependency scanner.

Regards,

Michael

> In particular, this is useful for performing search operations.
> 
> Remember: Visual Studio allows you to constrain multi-file searches a 
> number of ways, one of which is "Just this project".
> 
> When you have thousands of header files, having every header in your 
> codebase arbitrarily crammed into your project file means that every 
> project-only search is going to return too many results.
___
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] Make clean in VS can't delete read only files

[Michael Hertling]

On 11/10/2010 01:17 AM, James Bigler wrote:
> I have a build rule that copies files from the source tree to the build
> tree:
> 
> foreach( script ${scripts} )
>   set( src  "${CMAKE_CURRENT_SOURCE_DIR}/${script}" )
>   set( dest "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${script}" )
>   list( APPEND dest_files "${dest}" )
>   add_custom_command(
> OUTPUT "${dest}"
> COMMAND ${CMAKE_COMMAND} -E copy "${src}" "${dest}"
> MAIN_DEPENDENCY "${src}"
> COMMENT "Copying ${src} to ${dest}"
> VERBATIM
>   )
> endforeach()
> 
> add_custom_target( copy_scripts
>   ALL
>   DEPENDS ${dest_files}
>   )
> 
> This then runs commands such as this:
> "C:\Program Files (x86)\Programming\CMake 2.6\bin\cmake.exe" -E copy
> C:/code/rtsdk/rtmain/tests/Regression/scripts/correctness.rb
> C:/code/rtsdk/rtmain/build-32-vs9-c32/bin/correctness.rb
> 
> The problem I'm having is that when I go and do a make clean, I get errors
> that the destination files are read only.  This isn't unexpected as the
> source files are read only, but how do I work around this file permission
> issue in a portable way?
> 
> I don't want to use configure file, because I want the files to be copied at
> build time and not configure time.

Instead of "cmake -E copy" or CONFIGURE_FILE() which both preserve file
permissions, you might use FILE(COPY ... NO_SOURCE_PERMISSIONS) in a
CMake script triggered by your custom command, e.g.:

ADD_CUSTOM_COMMMAND(
  OUTPUT ...
  COMMAND ${CMAKE_COMMAND} -DSRC=... -DDSTDIR=... -P .../copy.cmake
  MAIN_DEPENDENCY ...
  COMMENT "Copying ... to ..."
  VERBATIM
)

The copy.cmake script may look just like:

FILE(COPY ${SRC} DESTINATION ${DSTDIR} NO_SOURCE_PERMISSIONS)

Note that you must provide a destination directory instead of a full
path, so use GET_FILENAME_COMPONENT() and FILE(RENAME ...) to adapt.

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 my_BouncyBall

[Michael Hertling]

On 11/07/2010 03:37 PM, luxInteg wrote:
> On Sunday 07 November 2010 11:34:47 Richard Wackerbarth wrote:
>> First let me suggest that you word your request in a more complete manner.
>> What "does not work"? 
> cant get an executable generated  because the  'COMMAND' syntax is incorrect"
> so could you suggest the correct syntax please?
> 
>> What were you expecting and what did you get?
>> It is difficult, if not impossible, for us to guess.
>>
>> I suspect that the problem is related to the ">" (specifying the output
>> file in Unix). Are you on a Un*x platform? 
> yes linux
>> Remember that CMake uses a
>> different syntax because it assumes that the platform may not be
>> Unix-based.
>>
>> I also have no idea just what "BouncyBall" is supposed to do
> generate BouncyBall.out
> 
>> They look very much like a call to the
>> Unix "diff" command to verify that the output matches some previous
>> version (stored in BouncyBall.out)
> correct
> 
> which requires the  generation  an executable file first.
> 
>>
>> Provide additional details. Then we may be able to be more helpful.
> 
> DETAILS: as requested:
> 
>  add_executable(BouncyBall BouncyBall.c)
>  find_library(OLD_LIBRARY OLD)
>  target_link_libraries(BouncyBall ${OLD_LIBRARY})
>  COMMAND(./BouncyBall > my_BouncyBall.out
>- diff BouncyBall.out my_BouncyBall.out)
>  
> 
> what is needed:-
> 
> 
> a) syntax for generating BouncyBall executable   with oppropriate linking to  
> ${OLD_LIBRARY}

The ADD_EXECUTABLE(), FIND_LIBRARY() and TARGET_LINK_LIBRARIES()
commands look good, provided the library OLD is actually found.

> b) syntax within cmake  for executing  BouncyBall executable   and diffing  
> output to 'existing'  outputfile  
> 
> i.e this bit:-
> (
>  COMMAND(./BouncyBall > my_BouncyBall.out   
> - diff BouncyBall.out   my_BouncyBall.out )
> )

Here, you might use a test driven by a simple CMake script:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BOUNCYBALL C)
ENABLE_TESTING()
FILE(WRITE ${CMAKE_BINARY_DIR}/bouncyball.out "bouncyball\n")
FILE(WRITE ${CMAKE_BINARY_DIR}/bouncyball.cmake "
EXECUTE_PROCESS(
COMMAND \${EXEC} COMMAND diff - \${FILE} RESULT_VARIABLE RESULT
)
IF(NOT RESULT EQUAL 0)
MESSAGE(FATAL_ERROR)
ENDIF()
")
FILE(WRITE ${CMAKE_BINARY_DIR}/bouncyball.c "
#include 
int main(void){
printf(\"bouncyball\\n\");
return 0;
}
")
ADD_EXECUTABLE(bouncyball bouncyball.c)
ADD_TEST(NAME bouncyball
COMMAND ${CMAKE_COMMAND}
-DEXEC=$
-DFILE=${CMAKE_BINARY_DIR}/bouncyball.out
-P ${CMAKE_BINARY_DIR}/bouncyball.cmake
)

After configuration, if you edit bouncyball.out you can see the test
pass or fail, depending on its contents; use "make test" or "ctest".

Regards,

Michael

> I hope I did provide   the example unix Makefile that is being translated.
> 
> thanks
> and
> regards
> 
>> On Nov 7, 2010, at 6:08 AM, luxInteg wrote:
>>> Greetings,
>>>
>>> I am learning cmake. and I have taken the following from an old
>>> Makefile:- INC = ../include/BouncyBall.h
>>>
>>> BouncyBall: BouncyBall.c library $(INC)
>>>
>>> ${CC} ${CFLAGS}  -o BouncyBall BouncyBall.c ../lib/libOLD.a
>>> ./BouncyBall > my_BouncyBall.out  - diff BouncyBall.out
>>> my_BouncyBall.out
>>>
>>> and  'translated'   for cmake  as the following:-
>>> ---
>>> add_executable(BouncyBall BouncyBall.c)
>>> find_library(OLD_LIBRARY OLD)
>>> target_link_libraries(BouncyBall ${OLD_LIBRARY})
>>> COMMAND(./BouncyBall > my_BouncyBall.out
>>>
>>> - diff BouncyBall.out my_BouncyBall.out)
>>>
>>> install(TARGETS
>>> BouncyBall
>>> BouncyBall.out
>>> my_BouncyBall.out
>>> DESTINATION bin)
>>> ---
>>> but it does not work
>>>
>>> advice would be appreciated
>>>
>>> sincerely
>>> luxInteg
___
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] make test missing

[Michael Hertling]

On 11/08/2010 10:03 PM, Jochen Issing wrote:
> Hi list,
> 
> I tried to add ctest to my project and did this by adding ENABLE_TESTING() 
> and several ADD_TEST(...) to my CMakeLists.txt file.
> The tests are run on executables, which are built inside a dedicated test 
> directory in my project root and the execs show up in my Makefile.
> After reading through some docs, I am told to call make test after building. 
> However, no target named 'test' is available.

I.e. it doesn't show up in the listing of "make help"?

> Here my question: Does my directory 'test' interfere with the 'test' rule or 
> do I have to install the executables before testing or do I still miss 
> something? 

On *nix, I can see the following CMakeLists.txt work:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(TEST C)
ENABLE_TESTING()
FILE(MAKE_DIRECTORY ${CMAKE_SOURCE_DIR}/test ${CMAKE_BINARY_DIR}/test)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(
main
PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/test
)
ADD_TEST(NAME main COMMAND main)

The output of "make test" - without installation - is:

Running tests...
Test project /home/hertling/work/cmake/issing/obj
Start 1: main
1/1 Test #1: main .   Passed0.00 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) =   0.11 sec

So, I'd conclude the "test" directories' presence doesn't matter,
nor does the fact if an installation has already been performed.

Maybe, you could post your CMakeLists.txt for further inspection.

Regards,

Michael

> Anyhow, 'ctest -D Experimental' seems to do something :/
> 
> Also, I am not sure if I need to setup a Dashboard-Server to use testing at 
> all. I suppose it's possible without a dashboard, but don't know how.
> Thanks in advance!
> Cheers,
> 
> - jochen
> gpg: 1024D/013400C7
___
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] call already made makefile

[Michael Hertling]

On 11/06/2010 07:10 PM, Alan W. Irwin wrote:
> On 2010-11-05 22:50-0700 SK wrote:
> 
>> On Fri, Nov 5, 2010 at 1:04 PM, Alan W. Irwin  
>> wrote:
>>> I agree the above idea should work, but dropping add_custom_command
>>> completely and moving the COMMAND to add_custom_target instead (and
>>> dropping all file DEPENDS for the custom target) is even a simpler way
>>> to insure COMMAND gets executed every time the custom target is
>>> built.
>>
>> Yes it always runs, but there is no "output" from add_custom_target.
> 
> True.
> 
>> When the external makefile produces an output needed by some larger
>> dependency chain, then add_custom_command is the only way.
> 
> You may be right for the general case.  However, note that since
> OUTPUT is involved the dependency chain you are talking about must be a
> file dependency chain that occurs as a result of a series of
> add_custom_command or add_custom_target commands.  Note an important
> limitation of such chains is those commands must appear in the same
> CMakeLists.txt file.
> 
> Note also that according to my experiments your general conclusion
> turns out not to be correct for the specific case of external
> libraries.
> 
> To be specific, here are the two different scenarios we are discussing
> for that case.
> 
> I.
> 
> add_custom_command(
>OUTPUT full_path_to_generated_library dummy
>COMMAND make
>WORKING_DIRECTORY full_path to where Makefile is located
>)
> 
> add_custom_target(
>extern_lib
>DEPENDS full_path_to_generated_library
>)
> 
> add_executable(myexecutable myexcutable.c)
> 
> target_link_libraries(myexecutable full_path_to_generated_library)
> 
> add_dependencies(myexecutable extern_lib)
> 
> II,
> 
> add_custom_target(
>extern_lib
>COMMAND make
>WORKING_DIRECTORY full_path to where Makefile is located
>)
> 
> add_executable(myexecutable myexcutable.c)
> 
> target_link_libraries(myexecutable full_path_to_generated_library)
> 
> add_dependencies(myexecutable extern_lib)
> 
> where the only difference between I and II is the
> add_custom_command/add_custom_target pair of I is replaced with a
> single add_custom_target with COMMAND specified in II.
> 
> My experiment consisted of touching the actual external library file
> that is referred to for an existing project that used the
> target_link_libraries command. That external library was built
> completely separately (unlike the above two scenarios).  But the
> result of touching that library was that my internal target (a library
> in this case) got relinked.  So in that case, there seemed to be no
> necessity at all that full_path_to_generated_library actually needed
> to appear in an OUTPUT in order for the internal target to be
> relinked. That is why I predict scenario II above should work with no
> problems.
> 
> To explain my reasoning further, With II, every time one of the source
> files of the externally generated library gets changed, then "make
> myexecutable" should rebuild that library through the _target_
> dependency between the myexecutable target and the extern_lib target.
> Because that external library rebuild necessarily changes the file
> full_path_to_generated_library, then myexecutable should be relinked
> because (according to my experiements) target_link_libraries always
> relinks whenever there is a change in the library file that is
> referred to _regardless of the source of the change to that file_.
> 
> Of course, although the above logic seems compelling, it needs to be
> verified by examples.  I am not in a good position to do that, but I
> assume from your posts about the specific external library case you do
> have an example of scenario I that does work properly for external
> libraries or can soon put one together.  If you make the trivial
> change to scenario II, does that example continue to work properly as
> predicted by the above logic?

IMO, the question anything boils down to is: Do you need the output of
a command as an input to ADD_{LIBRARY,EXECUTABLE}() or after a DEPENDS
clause within the same CMakeLists.txt? If you do you must use a custom
command because a custom target is, say, output-less, as SK has stated
correctly. Moreover, you must possibly take further measures to ensure
that the command runs when necessary, e.g. by an accompanying custom
target or a never existing dummy output.

If you do not need the command's output explicitly as an input or a
prerequisite you might get by with a sole custom target. In the above-
mentioned example, you do get by because the output is mentioned only
in TARGET_LINK_LIBRARIES() which results in a file-level dependency of
the link line on that output and no more; in particular, this wouldn't
enable a custom command. Here, in addition, you can afford to have the
custom target build each time as the foreign make command is supposed
to do nothing when there is nothing to do. A different configuration,
e.g. an expensive custom target or further dependencies of the output

Re: [CMake] CMAKE way to get leaf of file path

[Michael Hertling]

On 11/07/2010 02:07 AM, Russell L. Carter wrote:
> 
> Hi there,
> Happy cmake user here.  I want to retrieve the leaf name of
> the directory property "PARENT_DIRECTORY".  This is really
> a more general cmake question:  how do I most efficiently
> manipulate path components of the absolute pathnames that
> cmake uses and returns for many variables?
> 
> In the current case, suppose I have
> 
> "/home/me/project/src/module/help"
> 
> how do I, in the best CMAKE WAY, extract the leaf, "help"?
> 
> string(REGEXP) or something like that?
> 
> I would love to be able to run a bash script on the full
> path and return just the leaf...  can I do that?

You might try STRING(REGEX REPLACE "^.*/([^/]*)\$" "\\1" LEAF ${PATH}),
but also read about FILE(TO_CMAKE_PATH ...), FILE(TO_NATIVE_PATH ...)
and GET_FILENAME_COMPONENT().

Regards,

Michael

PS: Please don't start a new thread by replying to another one.
___
Powered by www.kitware.com

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

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

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

Re: [CMake] help with learning add_library

[Michael Hertling]

On 11/06/2010 05:26 PM, luxInteg wrote:
> Greetings,
> 
> I am learning cmake.
> 
> I have a question on  using add_library.  in my  project(learnCMAKE).  The 
> latter has:-
> 
> ---a) 2  source files   file1.c  file2.c
> ---b) the envar {CFLAGS}  set
> ---c)  need to generate  libLearnCMAKE.so and libLearnCMAKE.a

ADD_LIBRARY(LearnCMAKE-shared SHARED file1.c file2.c)
ADD_LIBRARY(LearnCMAKE-static STATIC file1.c file2.c)
SET_TARGET_PROPERTIES(LearnCMAKE-shared LearnCMAKE-static
PROPERTIES OUTPUT_NAME LearnCMAKE)

> ---d) need  to add preprocessor agruments -DXXX to CFLAGS  in the compilation 
> of  the source files  before liberies are archived  like so:-
> 
> gcc ${CFLAGS} -DDINT /path/to/file1.c
> gcc ${CFLAGS} -DDINT /path/to/file2.c
> 
> gcc ${CFLAGS} -DDLONG /path/to/file1.c
> gcc ${CFLAGS} -DDLONG /path/to/file2.c

SET_TARGET_PROPERTIES(LearnCMAKE-shared LearnCMAKE-static
PROPERTIES COMPILE_DEFINITIONS DINT)

or

SET_SOURCE_FILES_PROPERTIES(/path/to/file1.c /path/to/file2.c
PROPERTIES COMPILE_DEFINITIONS DINT)

or

SET_DIRECTORY_PROPERTIES(
PROPERTIES COMPILE_DEFINITIONS DINT)

or

ADD_DEFINITIONS(-DDINT)

or

SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DDINT")

If the CFLAGS environment variable is defined when CMake runs the first
time on the project the flags are taken for CMAKE_C_FLAGS, but consider
to set the latter in the CMakeLists.txt or from the command line or the
GUI, so you don't need to have a properly set up environment to succeed.

> How can this be achived in a marco or whatever with add_library ?
> Help would be appreciated

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 gfortran project question

[Michael Hertling]

On 11/05/2010 07:21 PM, luxInteg wrote:
> Greetings,
> 
> I have  a little learning progect using cmake with gfortran.  
> 
> SOURCE files: .f, .f  xxx.f  and .f .y
> 
> I  want to do the following:-
> 
> 
> a)   create a shared library libFFF.so and a static one  libFFF.a  (from   
> say 
> xxx.f and yyy.f)

ADD_LIBRARY(FFF-shared SHARED xxx.f yyy.f)
ADD_LIBRARY(FFF-static STATIC xxx.f yyy.f)
SET_TARGET_PROPERTIES(FFF-shared FFF-static PROPERTIES OUTPUT_NAME FFF)

> b)   find   installed  fortran  librar(ies)say libOLD.a  libOLD.so  and 
> link   libOLD.so to libFFF.so

FIND_LIBRARY(OLD-static libOLD.a ...)
FIND_LIBRARY(OLD-shared libOLD.so ...)
TARGET_LINK_LIBRARIES(FFF-shared ${OLD-shared})

> c)   when creating libFFF.a  tell compiler to compile in libOLD.a

TARGET_LINK_LIBRARIES(FFF-static ${OLD-static})

> d)   compile .f, .f  into   executible  AAA   to  link in  libFFF.so 

ADD_EXECUTABLE(AAA .f .f)
TARGET_LINK_LIBRARIES(AAA FFF-shared)

> e)   compile  .finto executible BBB and compile in  libFFF.a

ADD_EXECUTABLE(BBB .f)
TARGET_LINK_LIBRARIES(BBB FFF-static)

> I am a novice at cmake and some helo with a)-e) would be appreciated.

In short and not tested.

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] header files with visual studio

[Michael Hertling]

On 11/06/2010 12:20 PM, Eric Noulard wrote:
> 2010/11/6 Pedro d'Aquino :
>> On Friday, November 5, 2010, Oliver kfsone Smith 
>>>
>>> Thanks for the detailed response, Michael :)
>>>
>>> So, the question is actually:
>>>
>>> Is there a way to have CMake automatically add included headers to visual 
>>> studio project files or do you need to use a dependency system to generate 
>>> the lists by hand?
>>
>> Can't you just include "*.h" "*.hpp"? I find it scales much better
>> that listing each file.
> 
> Initially it may be a pain to list them but after a while its generally better
> to manually keep track of file (dis)appearing in your source tree.
> (which is usually what you do when using an IDE without CMake)
> 
> I.e. if those files are/were added "by hand" into the build system then they
> must but tracked by explicit list in CMakeLists.txt.
> 
> The only case (I see) you may faithfully glob for *.h *.whatever is when
> those are generated files.
> 
> Not doing that means
> 
> "I don't care about source file which are added/removed
>  I just want to compile those"
> 
> **MY** opinion is that this way of looking to source code is wrong.
> 
> That said I fully understand that the to CMake transition may be painful when
> the project is big.

Perhaps, one might come to a compromise:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(FILELIST C)
ADD_CUSTOM_TARGET(filelist
COMMAND ${CMAKE_COMMAND}
-DVAR=FILELIST
-DDIR=${CMAKE_SOURCE_DIR}
-DFILE=${CMAKE_BINARY_DIR}/filelist.dat
-P ${CMAKE_SOURCE_DIR}/filelist.cmake
)
IF(NOT EXISTS ${CMAKE_BINARY_DIR}/filelist.dat)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND}
-DVAR=FILELIST
-DDIR=${CMAKE_SOURCE_DIR}
-DFILE=${CMAKE_BINARY_DIR}/filelist.dat
-P ${CMAKE_SOURCE_DIR}/filelist.cmake
)
ENDIF()
INCLUDE(${CMAKE_BINARY_DIR}/filelist.dat)
ADD_EXECUTABLE(main ${FILELIST})

The ${CMAKE_SOURCE_DIR}/filelist.cmake script looks like:

FILE(GLOB FILELIST "${DIR}/*.c")
FILE(WRITE ${FILE} "SET(${VAR} ${FILELIST})\n")

Thus, the initial set of *.c files in CMAKE_SOURCE_DIR is gathered and
stored in the ${CMAKE_BINARY_DIR}/filelist.dat script as an assignment
to the variable FILELIST. Subsequently, this filelist.dat is read via
INCLUDE(), so CMake keeps track of it, i.e. changing the filelist.dat
results in a rebuild. Finally, the filelist custom target regenerates
filelist.dat by executing filelist.cmake. Hence, each time the set of
*.c files in CMAKE_SOURCE_DIR changes, a "make filelist" will update
filelist.dat, and the following "make" will rebuild - taking into
account the refreshed list of source files. Maybe, this approach
can be adapted to platforms other than *nix and large projects.

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] call already made makefile

[Michael Hertling]

On 11/06/2010 06:50 AM, SK wrote:
> On Fri, Nov 5, 2010 at 1:04 PM, Alan W. Irwin  
> wrote:
>> I agree the above idea should work, but dropping add_custom_command
>> completely and moving the COMMAND to add_custom_target instead (and
>> dropping all file DEPENDS for the custom target) is even a simpler way
>> to insure COMMAND gets executed every time the custom target is
>> built.
> 
> Yes it always runs, but there is no "output" from add_custom_target.
> When the external makefile produces an output needed by some larger
> dependency chain, then add_custom_command is the only way.

If you want to ensure that an output-producing custom command without
dependencies runs each time its output - present or not - is referred
to you might use a second, say, dummy output which never exists, e.g.:

ADD_CUSTOM_COMMAND(
OUTPUT /libxyz.so dummy
COMMAND make
WORKING_DIRECTORY 
)

Thus, there is no need for a triggering custom target unless the,
say, productive output is referenced from another CMakeLists.txt.

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] call already made makefile

[Michael Hertling]

On 11/05/2010 05:23 AM, SK wrote:
> On Thu, Nov 4, 2010 at 6:09 PM, Alan W. Irwin  
> wrote:
>> then the custom make command
>> should always be run (since it has no DEPENDS option),
> 
> Alan, you are absolutely right!!  I missed this since the external
> makefile I need actually does have a dependency to create the makefile
> itself.  So, the custom command only ran when the single explicit
> dependency was out of date.  I can solve that some other way and I
> appreciate all your effort to straighten this out.  I wish the
> document would have explicitly stated that the command always runs
> without a dependency, though that is the intuitive course of action.

AFAIK, a custom command without dependencies doesn't run if its OUTPUT
exists; see the following CMakeLists.txt and the generated Makefiles:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INDEPENDCUSTOMCOMMAND C)
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_BINARY_DIR}/main.h
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/main.h)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "
#include \"main.h\"
int main(void){return 0;}
")
ADD_EXECUTABLE(main main.c main.h)

The sole possibility to (re)run the custom command is to delete main.h;
if main.h exists the command never runs. You might even have a foreign
main.h: Try "cmake " followed by "touch main.h" from
within an empty build directory, and you won't see the custom command
run. In ${CMAKE_BINARY_DIR}/CMakeFiles/main.dir/build.make, the related
lines are:

main.h:
...
.../cmake -E touch .../main.h

So, the commands associated with make's "main.h" target aren't executed
if make detects that main.h is already present. Thus, a dependency-less
custom command doesn't run each time; rather, it runs only if its output
doesn't exist.

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] call already made makefile

[Michael Hertling]

On 11/05/2010 02:09 AM, Alan W. Irwin wrote:
> On 2010-11-04 16:29-0700 SK wrote:
> 
>> On Sat, Oct 30, 2010 at 8:31 AM, Alan W. Irwin
>>  wrote:
>>> On 2010-10-29 20:50-0700 mina adel wrote:
>>>

 Hi All

 I have an open source code that I use in my project. This open source code
 already has Makefile coded for it.

 I want to use cmake so that before it compile my project it first call the
 cmake of these open source code, which will compile it to .la library.
>>>
>>> ..make?

 Then using this library, it compile my code.
>>>
>>> I assume from the context you mean make rather than cmake above.
>>>
>>> To run make (or any command) at run-time, use the combination of
>>> add_custom_command and add_custom_target.  Basically,
>>> add_custom_command creates an OUTPUT file (say your library) at run
>>> time, and add_custom_target file-depends on that file and creates a
>>> CMake target corresponding to the custom command which you can add as
>>> a dependency of your application target.  This insures make will be run (if
>>> the library is not up to date) before your application is built.
>>>
>>
>> No, this does not work when the external command is a make process.
>> The problem is that the "output" of add_custom_command() is a target
>> with it's own dependencies.
> 
> I don't understand your remark since the OUTPUT of add_custom_command
> must refer to a file not a target, and there is a big distinction
> between those two concepts in CMake.  That's why I emphasize when
> a file is indicated and when a target is indicated below.
> 
>> The external make process must always run
>> in order catch dependencies that only the external make knows about.
>> The only way to make sure the make process always runs is to use
>> add_custom_target(), but alas, add_custom_target does allow us to
>> specify an output.
>>
>> See this thread from a few days ago: add_custom_command depends on
>> output from add_custom_target.
>>
>> As far as I know, there is no satisfactory way to do use external
>> makefiles with CMake.  I'm all ears if anyone has suggestions.
>>
> 
> In the past I have been able to use an external set of Makefiles with
> no problems. However, I eventually took my own advice and replaced
> that method with one that used cmake.  So I don't have any current
> good examples, and my remarks below are from memory. However, I think
> it should be completely straightforward to do what you like if you
> read the cmake documentation for add_custom_command and
> add_custom_target carefully.
> 
> Here is schematically what you have to do:
> 
> add_custom_command(
>OUTPUT full_path_to_generated_library
>COMMAND make
>WORKING_DIRECTORY full_path to where Makefile is located
>)
> 
> add_custom_target(
>extern_lib
>DEPENDS full_path_to_generated_library
>)
> 
> add_executable(myexecutable myexcutable.c)
> 
> target_link_libraries(myexecutable full_path_to_generated_library)
> 
> add_dependencies(myexecutable extern_lib)
> 
> In sum, target_link_libraries tells how to link the executable file
> associated with the myexecutable target to the library _file_
> full_path_to_generated_library, add_dependencies makes sure the
> _custom target_ extern_lib is built before the _target_ myexecutable is
> built, and the _file_ DEPENDS of add_custom_target makes sure the
> custom make command is run every time there is an attempt to build the
> myexecutable (and therefore extern_lib) target.
> 
> Please check my memory of the correct way to do this by using the
> touch command.  For example, if you touch one of the source files for
> the external library, then I believe with the above scenario if you
> subsequently run "make myexecutable", then the custom make command
> should always be run (since it has no DEPENDS option), and therefore
> the external library will automatically be rebuilt (assuming those
> external Makefiles had done their dependencies properly), and
> myexecutable relinked.

AFAIK, this can be simplified by dropping the custom command:

add_custom_target(
   extern_lib
   COMMAND make
   WORKING_DIRECTORY full_path to where Makefile is located
)
add_executable(myexecutable myexcutable.c)
target_link_libraries(myexecutable full_path_to_generated_library)
add_dependencies(myexecutable extern_lib)

As the custom target is always out of date, make is invoked each time,
and due to ADD_DEPENDENCIES(), it is invoked before the executable is
examined for being out of date. If that results in a renewed external
library the executable gets relinked. Additionally, the question if a
custom command without DEPENDS clause does always run is avoided.

Regards,

Michael

> Of course, use "make VERBOSE=1" to follow exactly what commands are
> being run when testing file dependencies and associated target
> dependencies with the touch command.  Also, I believe it ultimately
> would be a good idea to replace all builds of external libraries with
> CMake-based builds sin

Re: [CMake] building static binaries

[Michael Hertling]

On 11/02/2010 10:54 PM, Szilárd Páll wrote:
> Hi,
> 
> I've been trying to implement a feature which would enable building
> static binaries with cmake, but I've got completely stuck, I hope
> someone can hint me what's the best way to do this.
> 
> What I've done is a 2 stage solution for making static binaries:
> 
> 1) Telling cmake to prefer picking up ".a"-s when searching for
> libraries (CMAKE_FIND_LIBRARY_SUFFIXES).
> 
> This works fine, but referring to file extensions/endings might not be
> general enough. Making it less platform-dependent would require
> rewriting the way external libraries are treated: instead of adding
> them with full path we'd need to add -Lpath -llibname separately. Any
> other ways for doing this?
> 
> 
> 2) Telling cmake to use static system libraries.
> 
> This should work with the target property LINK_SEARCH_END_STATIC which
> essentially should result in a the system libs linked in statically
> whenever possible (depending on the platform). Well, it seems that
> even in fairly straightforward situations (Linux + gcc) I get the a
> linker error: /usr/bin/ld: cannot find -lgcc_s.
> 
> Obviously, libgcc_s.a is not available, but by looking at the verbose
> output, the implicit gcc linker call contains the "-Wl,-Bstatic"
> argument. This AFAIK is not correct, or more precisely not enough to
> just tell ld to link statically, gcc also has to know about it
> (through the "-static" argument). Can anyone confirm this?
> 
> 
> I'd be grateful for tips on how to fix the issue with 2), but I'm open
> for other portable (and preferably elegant) solutions.

FYI: See [1], and in particular [2] and [3].

Regards,

Michael

[1] http://www.mail-archive.com/cmake@cmake.org/msg21106.html
[2] http://www.mail-archive.com/cmake@cmake.org/msg21317.html
[3] http://www.mail-archive.com/cmake@cmake.org/msg21416.html
___
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.3-rc4 ready for testing!

[Michael Hertling]

On 11/01/2010 01:22 AM, Marcus D. Hanwell wrote:
> On Sun, Oct 31, 2010 at 7:30 PM, Campbell Barton  wrote:
>> Hi I saw in the log you added a case for Python 2.7,
>> Would you be able to add a check for Python 3.x ?
>>
>> For Blender 3D we use CMake and only support python 3.x series.
> 
> I added that (or part of it at least). I suspect it is too late, and
> we really need to add a variable to request Python 3. That would be
> too big of a change this late in the RC series. We could work on
> something, with a view to getting it in CMake 2.8.4, that you could
> add to Blender's CMake module path until the release.
> 
> I think for it to be general enough we would need something that
> defaulted to Python 2.x, but could look for Python 3 if the project
> requested it. I was not sure how best to handle this, and wanted to
> make sure this release found Python 2.7. I know for most of the
> project I develop we explicitly don't want Python 3 as our stuff is
> not ready for it yet.

Perhaps, the version parameter of FIND_PACKAGE() can be used for this
purpose. Due to the prevalence of Python 2, one could agree on 2.x as
the default if no version is specified whereas 3.x may be explicitly
requested as FIND_PACKAGE(Python{Interp,Libs} 3 ...). IMO, this is a
more straight approach than introducing additional variables for the
version selection and should mean no harm to backward compatibility.

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] Flags when building objects or a target

[Michael Hertling]

On 11/02/2010 01:58 AM, mina adel wrote:
> Hi
> 
> 
> I have a problem when cmake builds the objects for shared library.
> 
> I have the following in my cmaklists.txt
> 
> set(SIMULATOR_SOURCES circuit.cc matrix.cc plot.cc sources.cc 
> sparse.cc btzdense.cc element.cc util.cc parse.c 
> netlist_parse.y netlist_lex.l circuit_step.cc zmatrix.cc 
> hash_key.cc zsparse.cc zbtzdense.cc mtutil.cc)
> 
> add_library(simulator SHARED ${SIMULATOR_SOURCES})
> 
> set_target_properties(simulator PROPERTIES LINK_FLAGS 
> "-I../sparse-libs/include")
> target_link_libraries(simulator ${LIBS} "models/libmodels.a 
> ../sparse-libs/libsparse.a") 
> 
> 
> 
> However, target_link_libraries does not include the flags when building the 
> objects. it only does when building the library. [...]

As the name LINK_FLAGS denotes, these settings are applied when a target
is linked, i.e. built from its object files and checked for references
to libraries. They don't come into play when sources are compiled to
object files, so "-I" within LINK_FLAGS is of no use.

> [...] And I do not want to add 
> (-I../sparse-libs/include) for all my objects. 

Consider to set the COMPILE_FLAGS source property on those files which
you want to be compiled with "-I" flags for special include directories.

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] add_custom_command depends on output from add_custom_target

[Michael Hertling]

On 11/01/2010 10:47 PM, SK wrote:
> I know add_custom_target does not produce output as far as CMake is
> concerned.  My situation is as follows:
> 
> A traditional make process that I cannot modify produces a target on
> which I must do some post-processing.
> 
> I use add_custom_target to force the makefile to always run. I use
> add_custom_command for my post-processing steps.
> 
> How do I setup a dependency for the post-processing steps? I don't
> want to run these steps unless the external make actually updated its
> target.

Possibly, you can use ADD_CUSTOM_COMMAND(TARGET ... POST_BUILD ...):

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(POSTPROCESSING NONE)
ADD_CUSTOM_TARGET(t ALL
${CMAKE_COMMAND} -E echo "Building target t"
VERBATIM)
ADD_CUSTOM_COMMAND(TARGET t POST_BUILD
COMMAND ${CMAKE_COMMAND} -E echo "Post-processing target t"
VERBATIM)

So, the custom command always runs after the custom target's one.

> The add_custom_command cannot use the name of the add_custom_target as
> a DEPENDS. I tried this and it assumes that the add_custom_target name
> is just a file and cannot find it.

IMO, this is strange. Indeed, the following doesn't work:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CUSTOMDEPENDS NONE)
ADD_CUSTOM_TARGET(t
${CMAKE_COMMAND} -E echo "Building target t"
VERBATIM)
ADD_CUSTOM_COMMAND(OUTPUT stamp
COMMAND ${CMAKE_COMMAND} -E touch stamp
DEPENDS t
VERBATIM)
ADD_CUSTOM_TARGET(main ALL
${CMAKE_COMMAND} -E echo "Building target main"
DEPENDS stamp
VERBATIM)

When running make, it correctly builds target t, but subsequently, it
bails out saying "No rule to make target `t', needed by `stamp'." From
the documentation of ADD_CUSTOM_COMMAND(), it's not clear why there is
a restriction of that kind w.r.t. custom targets. Perhaps, someone can
give us a hint if this is intended behaviour or should be considered as
erroneous.

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] ADD_CUSTOM_COMMAND, crating file with echo redirection, platform independent

[Michael Hertling]

On 10/27/2010 08:02 PM, Arne Pagel wrote:
> Hello,
> 
> I need a custom command in my build process.
> The tool that I am using has a small problem, I have to insert a line of code 
> in
> the output file manually:
> #include 
> 
> I tried this with echo and output redirection:
> echo "#include " > images.c
> 
> The tool, gdk-pixbuf-csource, is not able to generate a file, therefor its 
> output has to be 
> redirected to the file too:
> gdk-pixbuf-csource --raw pix1 ./images/pix1.png >> images.c
> 
> I can get it work one linux and win32 system, but with different syntax:
> 
> This works on a win32 System:
> 
> ADD_CUSTOM_COMMAND (OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/images.c
>   COMMAND ${CMAKE_COMMAND} -E echo "\#include " > 
> images.c
>  COMMAND gdk-pixbuf-csource --raw pix1 ./images/pix1.png 
> >> images.c
>  DEPENDS ./images/pix1.png )
> 
> 
> This works on a linux System:
> 
> ADD_CUSTOM_COMMAND (OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/images.c
>  COMMAND echo "\"""#include""" "\"" > images.c
>  COMMAND gdk-pixbuf-csource --raw pix1 ./images/pix1.png 
> >> images.c
>  DEPENDS ./images/pix1.png )
> 
> I tried many variations of above examples, but I can't get running on both 
> systems with the same 
> syntax, any idea what might be right?
> 
> Perhaps there is another way then "echo" to write something in a file, I 
> tried FILE(WRITE) but I 
> failed with this.
> 
> I could make a file with the include line already inserted and than try to 
> copy it, I saw some 
> commands for that, is this the better Way? Actually I don't prefer this, I 
> don't want to have a 
> strange single-line source file in the project.

Possibly, you can use a CMake script with EXECUTE_PROCESS() and FILE():

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(PIXBUF NONE)
FILE(WRITE ${CMAKE_BINARY_DIR}/pixbuf.cmake "
EXECUTE_PROCESS(COMMAND gdk-pixbuf-csource --raw \${SRC}
OUTPUT_VARIABLE PIXBUF)
FILE(WRITE \${DST} \"#include \n\")
FILE(APPEND \${DST} \${PIXBUF})
")
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/test.c
COMMAND ${CMAKE_COMMAND}
-DSRC=${CMAKE_SOURCE_DIR}/test.png
-DDST=${CMAKE_BINARY_DIR}/test.c
-P ${CMAKE_BINARY_DIR}/pixbuf.cmake
DEPENDS ${CMAKE_SOURCE_DIR}/test.png)
ADD_CUSTOM_TARGET(pixbuf DEPENDS ${CMAKE_BINARY_DIR}/test.c)

The pixbuf.cmake script gathers the output of gdk-pixbuf-csource and
appends it to the resulting file which already contains the include
line. This approach should work in a platform-independent manner.

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] A question about cache variables

[Michael Hertling]

On 10/26/2010 08:47 PM, mina adel wrote:
> 
> 
> Hi All,
> I have a problem with cache variables in cmake.
> 
> I want to check the combiler for a certain flag -C99 flag. So, I used the 
> following statement
> CHECK_C_COMPILER_FLAG("-C99" FLAG_OK)
> 
> The problem is that we I ran cmake for the first time it said that c99 is not 
> found and set the FLAG_OK variable in CMakeCache.txt to 0.
> 
> Now, I fixed the problem =in the compiler to make it support -C99. But cmake 
> doesnot check the flag any more and just keep saying not found. This is 
> becuase 
> the FLAG_OK is already equals  to 0 in cache file.
> 
> Is there any way to delete the cahce variable. or force cmake to check for 
> the 
> flag every time I run it?

Rerun CMake with -UFLAG_OK or restart from within an empty build
directory or use UNSET(FLAG_OK CACHE) in your CMakeLists.txt, but
note: The purpose of caching is to avoid finding out the concerned
variables' values every time CMake runs, and the capabilities of a
compiler w.r.t. the acceptance of flags usually don't change often.

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] Ctest applied in a sub dir

[Michael Hertling]

On 10/24/2010 12:18 PM, Yann COLLETTE wrote:
> Hello,
> 
> I have used cmake to build an executable (which is 
> ${CMAKE_EXECUTABLE_DIR}/myprog.exe).
> I wanted to use ctest to test my executable. But I need to execute this 
> program in specific directories with various data set (in 
> ${CMAKE_SOURCE_DIR}/tests/first_test for example).
> 
> Is it possible to do this with ctest ?

You might use "cmake -E chdir" as a simple test driver:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CWD C)
ENABLE_TESTING()
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "
#include
#include
int main(void)
{
 char cwd[1000];
 getcwd(cwd,sizeof cwd);
 printf(\"CWD: %s\\n\",cwd);
 return 0;
}
")
ADD_EXECUTABLE(main main.c)
ADD_TEST(NAME maintest
COMMAND ${CMAKE_COMMAND} -E chdir /var/tmp $)

So, "ctest -V" issues "1: CWD: /var/tmp"; adapt for non-*nices.

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] Python test scripts

[Michael Hertling]

On 10/24/2010 01:26 AM, Bill Spotz wrote:
> Hi,
> 
> Is there a standard way to make tests for python extension modules?
> 
> Currently, I copy test scripts from the source directory to the binary 
> directory.  I would like to augment this by making the first line of my script
> 
>   #! ${PYTHON_EXECUTABLE}
> 
> but the only copy facility I see that supports this substitution is
> 
>   CONFIGURE_FILE(...)
> 
> The problem with this is that the file gets copied over during configuration, 
> and it would be much preferable to have it copied during the build phase.  Is 
> there a copy facility that performs substitutions that executes during the 
> build phase?

You might use a CMake script which is executed at build time:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(PYTHONTEST C)
SET(PYTHON_EXECUTABLE "path/to/python")
FILE(WRITE ${CMAKE_BINARY_DIR}/pythontest.py.in "#! @interpre...@\n")
FILE(WRITE ${CMAKE_BINARY_DIR}/pythontest.cmake "
CONFIGURE_FILE(${CMAKE_BINARY_DIR}/pythontest.py.in
   ${CMAKE_BINARY_DIR}/pythontest.py)\n")
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/pythontest.py
COMMAND ${CMAKE_COMMAND} -D INTERPRETER=${PYTHON_EXECUTABLE}
 -P pythontest.cmake
DEPENDS ${CMAKE_BINARY_DIR}/pythontest.py.in)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c pythontest.py)

So, CONFIGURE_FILE() is delayed until the custom command's invocation.
Anyway, the variables' values that are subject to substitution, i.e.
INTERPRETER in the example, must be provided at configuration time.

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] Linking with a Shell Script

[Michael Hertling]

On 10/22/2010 09:21 PM, Bob Torgerson wrote:
> To Whom It May Concern:
> 
> We have a shell script available on our system that is used in the common
> linking stage of making a set of executables that we would like to use for
> in CMake. We are not entirely certain how this can be done outside of
> possibly passing a set of command line options to a custom target that would
> use that shell script. The script is used to gather a set of libraries [...]

Although I don't know what your script does exactly - e.g., does it
drive the entire linking stage or does it just return the names of
libraries to link against, like pkg-config - I could imagine the
following alternatives:

1) Use EXECUTE_PROCESS() to execute your script at configuration time
   and put the results in a TARGET_LINK_LIBRARIES() invocation or the
   LINK_FLAGS target properties. IMO, the former should be preferred.
2) With Makefile generators: Use the RULE_LAUNCH_LINK global/target/
   directory property to integrate your script in the linking stage.
2) Modify the CMAKE__LINK_EXECUTABLE variables locally in the
   directories of the concerned targets for the same purpose.

> [...] that
> belong to a third party package.

Perhaps, you might consider to turn your script into a find module for
the third party package, so you can use FIND_PACKAGE() to obtain the
libraries that package provides.

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] cannot include txx files using CMake

[Michael Hertling]

On 10/20/2010 07:55 PM, Prathamesh Kulkarni wrote:
> I do not understand why I am having errors for only .txx files and not for
> .cpp files placed in the same common folder. Any help would be highly
> appreciated. Right now, I am forced to paste common the files in all the
> project folders where ever they are required.

Does ${OCTCommon_SOURCE_DIR}/src appear in the include path, i.e. have
you said INCLUDE_DIRECTORIES(${OCTCommon_SOURCE_DIR}/src) and have you
said it at the right place? How do the #include directives for the txx
files look like? Do they involve subdirectories, e.g. do they possibly
read "#include "? Could you post the
complete compile line which fails due to that missing include file?

Regards,

Michael

> On Wed, Oct 20, 2010 at 12:13 PM, Prathamesh Kulkarni <
> prathameshmkulka...@gmail.com> wrote:
> 
>> Thanks, I tried getting rid of the GLOB. But I am still getting the same
>> error as earlier:
>>
>>  fatal error C1083: Cannot open include file:
>> 'itkImageToVTKImageFilter.txx': No such file or directory
>>
>> (This file is present in a common directory)
>>
>> The CMakeLists now looks like this:
>>
>>
>> SET(IMPORTED_SRCS
>>  ${OCTIO_SOURCE_DIR}/src/OCTBScan.cpp
>>  ${OCTIO_SOURCE_DIR}/src/OCTCScan.cpp
>>  ${OCTIO_SOURCE_DIR}/src/OCTBScanHeader.cpp
>>  ${OCTIO_SOURCE_DIR}/src/OCTCScanHeader.cpp
>>  ${OCTCommon_SOURCE_DIR}/src/OCTCommon.cpp
>>  ${OCTCommon_SOURCE_DIR}/src/itkImageToVTKImageFilter.txx
>>  ${OCTCommon_SOURCE_DIR}/src/itkVTKImageToImageFilter.txx
>>  )
>>
>> SET(IMPORTED_HDRS
>>  ${OCTIO_SOURCE_DIR}/include/OCTBScan.h
>>  ${OCTIO_SOURCE_DIR}/include/OCTCScan.h
>>  ${OCTIO_SOURCE_DIR}/include/OCTBScanHeader.h
>>  ${OCTIO_SOURCE_DIR}/include/OCTCScanHeader.h
>>  ${OCTCommon_SOURCE_DIR}/include/OCTCommon.h
>>  ${OCTCommon_SOURCE_DIR}/include/itkImageToVTKImageFilter.h
>>  ${OCTCommon_SOURCE_DIR}/include/itkVTKImageToImageFilter.h
>>  )
>>
>>
>> #FILE(GLOB SRCS "src/*.cpp" "src/*.c" "src/*.txx" ${IMPORTED_SRCS})
>> #${IMPORTED_SRCS1})
>> #FILE(GLOB HDRS "include/*.h" ${IMPORTED_HDRS}) #${IMPORTED_HDRS1})
>>
>> SET(SRCS
>>  ./src/OCTBScanVisualization.cpp
>>  ./src/OCTCScanVisualization.cpp
>>  ./src/OCTVisualization_main.cpp
>>  #${IMPORTED_SRCS}
>> )
>>
>> SET(HDRS
>>  ./include/OCTBScanVisualization.h
>>  ./include/OCTCScanVisualization.h
>>  #${IMPORTED_HDRS}
>>  )
>>
>>
>> ADD_EXECUTABLE(OCTVisualization ${SRCS} ${HDRS} ${IMPORTED_SRCS}
>> ${IMPORTED_HDRS})
>>
>>
>> What am I doing wrong here?
>>
>> - Prathamesh
>>
>>
>> On Wed, Oct 20, 2010 at 11:26 AM, John Drescher wrote:
>>
>>> On Wed, Oct 20, 2010 at 12:19 PM, Prathamesh Kulkarni
>>>  wrote:
 Okay, could you please suggest an alternative over this issue?

>>>
>>> I add each file one by one in variables. The following is from an app
>>> used for unit testing my Qt SQLITE database for my current
>>> application.
>>>
>>> SET( DEMO_SRCS
>>>./src/main.cxx
>>>./src/MainWindow.cxx
>>>./src/CmdCreateDB.cxx
>>>./src/CmdAddUser.cxx
>>>./src/CmdAddStudy.cxx
>>>./src/CmdAddCase.cxx
>>>./src/CmdAddImage.cxx
>>>./src/CmdAddCaseAltID.cxx
>>>#./src/CmdAddCaseLocation.cxx
>>>./src/CmdAddImageSeries.cxx
>>>./src/CmdAddStudyMode.cxx
>>>./src/CmdAddSRSMPart.cxx
>>>./src/CmdAddSRSMCasePart.cxx
>>>#./src/CmdAddStudySMPart.cxx
>>>./src/CmdUpdateRSSSMCompletion.cxx
>>>./src/CmdSetCurrentReaderStudyMode.cxx
>>>./src/CmdGetStudyModeReaderParticipation.cxx
>>>./src/CmdGetReaderTotalCaseCount.cxx
>>>./src/CmdGetReaderTotalCaseList.cxx
>>>./src/CmdGetReaderCompletedCaseCount.cxx
>>>./src/CmdGetReaderCompletedCaseList.cxx
>>>./src/CmdGetReaderRecentCaseCount.cxx
>>>./src/CmdGetReaderRecentCaseList.cxx
>>>./src/CmdCounterBalanceStudyModes.cxx
>>>./src/CmdUpdateAdmin.cxx
>>>./src/CmdLstReadersInStudy.cxx
>>>./src/CmdAddReaderStudyModeCompletion.cxx
>>>./src/CmdAddReaderCaseCompletion.cxx
>>>./src/CmdTestImageSeriesCosines.cxx
>>>./src/CmdVerifyDB.cxx
>>> )
>>>
>>> SET( DEMO_HDRS
>>>./Include/CmdCreateDB.h
>>>./Include/CmdAddUser.h
>>>./Include/CmdAddStudy.h
>>>./Include/CmdAddCase.h
>>>./Include/CmdAddImage.h
>>>./Include/CmdAddCaseAltID.h
>>> #   ./Include/CmdAddCaseLocation.h
>>>./Include/CmdAddImageSeries.h
>>>./Include/CmdAddStudyMode.h
>>>./Include/CmdAddSRSMPart.h
>>>#./Include/CmdAddStudySMPart.h
>>>./Include/CmdAddSRSMCasePart.h
>>>./Include/CmdUpdateRSSSMCompletion.h
>>>./Include/CmdSetCurrentReaderStudyMode.h
>>>./Include/CmdGetStudyModeReaderParticipation.h
>>>./Include/CmdGetReaderTotalCaseCount.h
>>>./Include/CmdGetReaderTotalCaseList.h
>>>./Include/CmdGetReaderCompletedCaseCount.h
>>>./Include/CmdGetReaderCompletedCaseList.h
>>>./Includ

Re: [CMake] ADD_TEST and WORKING_DIRECTORY

[Michael Hertling]

On 10/20/2010 09:05 AM, Michael Wild wrote:
> 
> On 20. Oct, 2010, at 9:01 , Micha Renner wrote:
> 
>> Is there a way to specify a WORKING_DIRECTORY for ADD_TEST, similar
>> ADD_CUSTOM_COMMAND?
>>
>> Greetings
>>
>> Micha
> 
> 
> No, unfortunately not. You will have to wrap EXECUTE_PROCESS in a CMake 
> script and use that script as the test using "${CMAKE_COMMAND} -P 
> /path/to/script.cmake".

Perhaps, one could also use "cmake -E chdir" as a simple test driver:

ADD_TEST(NAME 
 COMMAND ${CMAKE_COMMAND} -E chdir 
 $...)

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] linking main Fortran and C++

[Michael Hertling]

On 10/19/2010 03:43 AM, Michael Scot Breitenfeld wrote:
>   My main program is in Fortran and I have couple of
>   files that are in C++. When I try to make the library,
>   CMake uses CXX linking (archiving) to make the library.
> 
>   Which I guess is ok, but then when it links the main program it
>   thinks that it is a CXX executable and uses the C++ compiler and
>   not the Fortran compiler so compilation fails.
> 
>   How do I tell cmake to use fortran instead, I
>   thought it would automatically do this from the .f90 suffix. I'm
>   using cmake 2.8.1.

Set the LINKER_LANGUAGE property of your main program target
to "Fortran", and see the CMAKE__LINKER_PREFERENCE and
CMAKE__LINKER_PREFERENCE_PROPAGATES variables for more
information.

Regards,

Michael

> My test:
> 
> PROJECT( Test )
> 
> SET(PACKAGE_NAME "TEST")
> 
> CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
> 
> SET (CMAKE_Fortran_COMPILER  gfortran)
> SET (CMAKE_CC_COMPILER  gcc)
> SET (CMAKE_CXX_COMPILER  g++)
> 
> # libraries are all shared by default
> option(BUILD_SHARED_LIBS "Build shared libraries" OFF)
> 
> ENABLE_LANGUAGE(Fortran)
> 
> SET(F_OBJ submain.f90)
> 
> SET(C_OBJ test.cpp)
> 
> ADD_LIBRARY (name STATIC ${F_OBJ} ${C_OBJ})
> 
> ADD_EXECUTABLE(a.out main.f90)
> 
> TARGET_LINK_LIBRARIES(a.out name)
___
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] Escaping semicolons in COMPILE_FLAGS on msvc

[Michael Hertling]

On 10/18/2010 06:50 PM, David Genest wrote:
> Hi, 
> 
> I have tried and tried, but haven't succeeded to include a semicolon as a 
> COMPILE_FLAGS property for a file. I turn to you for wisdom:
> 
> I need to get this as a result in the pre-processor definitions: 
> 
> MYPATH=\"d:\\;.\\Lib\"
> 
> But when I use the following escape sequence in set_source_files_properties:
> 
> set_source_files_properties(source.c PROPERTIES COMPILE_FLAGS 
> "-DMYPATH=\\\"d:\\\;.Lib\\\"")
> 
> the generated result is: MYPATH=\"d:\\";".\\Lib\"
> 
> note the quoted semicolon. Is there a quoting workaround to allow unquoted 
> semicolons?

FYI: On *nix, the following CMakeLists.txt

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(GENEST C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/main.c
PROPERTIES COMPILE_FLAGS "-DMYPATH=\\\"d:\\\;.Lib\\\"")
GET_SOURCE_FILE_PROPERTY(f ${CMAKE_BINARY_DIR}/main.c COMPILE_FLAGS)
MESSAGE("COMPILE_FLAGS: ${f}")
ADD_EXECUTABLE(main main.c)

results in

COMPILE_FLAGS: -DMYPATH=\"d:\\;.\\Lib\"

as you desire, and the compile command shows up as

...gcc -DMYPATH=\"d:\\;.\\Lib\" -o .../main.c.o -c .../main.c

also as desired, but fails since the shell interprets this line as an
invocation of gcc followed by an invocation of a .\Lib" command. Thus,
your issue seems to be related to your platform or the generator you
use, resp. BTW, which string do you want to see in your preprocessed
source file, i.e. what is MYPATH expected to be expanded to exactly,
and have you considered to use the COMPILE_DEFINITIONS properties
instead of COMPILE_FLAGS?

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] Last minute build-date file.

[Michael Hertling]

On 10/15/2010 04:14 PM, william.croc...@analog.com wrote:
> Hello:
> 
> If my app requires relinking, then at link time
> I would like to capture the current date and time and place it
> in a last-minute source file which is linked with the application.
> Following is my attempt at this with CMake.
> 
> The problems I can see are:
> 1 - It is not portable as it uses the OS date command.
> 2 - It is not portable as it calls gcc directly.
> 3 - It will not work with Debug or Release builds unless
>  I set additional target LINK_FLAGS_ properties.
> 4 - I wish the creation of the link_date.cc file could be
>  done inline of the add_custom_command instead of requiring
>  a separate file. (I got into quoting hell.)
> 5 - Sneaking link_date.o onto the link line with the LINK_FLAGS
>  property is kind of a hack.
> 
> Suggestions please.
> 
> Thanks in advance.
> 
> Bill
> 
>  CMake code --
> 
> # Note that this is a simplified version of the real thing
> # and may contain syntax errors.
> 
> add_executable( myapp myapp.cc  )
> target_link_libraries( myapp lib1 lib2 )
> set_target_properties( myapp PROPERTIES LINK_FLAGS link_date.o )
> 
> add_custom_command(
>  TARGET myapp PRE_LINK
>  COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/create_link_date
>  COMMAND gcc -m32 -c -I${UTILDIR} link_date.cc
>  COMMENT "Make the link_date file"
>  VERBATIM
> )
> 
> - Contents of create_link_date --
> 
> #!/bin/csh
> 
> echo 'const char *link_date() { return("'`date`'"); }' > link_date.cc

You might use CMake's --build option when hooking into the linking stage:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LINKDATE C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "
#include 
int main(void)
{
printf(\"%s\\n\",linkdate());
return 0;
}")
FILE(WRITE ${CMAKE_BINARY_DIR}/linkdate.c.in "
const char *linkdate() { return(\"@linkd...@\"); }
")
FILE(WRITE ${CMAKE_BINARY_DIR}/linkdate.cmake "
EXECUTE_PROCESS(
COMMAND date
OUTPUT_VARIABLE LINKDATE
OUTPUT_STRIP_TRAILING_WHITESPACE
)
CONFIGURE_FILE(\${SRC} \${DST} @ONLY)
")
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_BINARY_DIR}/linkdate.c
COMMAND ${CMAKE_COMMAND} -DSRC=linkdate.c.in -DDST=linkdate.c
 -P linkdate.cmake
DEPENDS ${CMAKE_BINARY_DIR}/linkdate.c.in)
ADD_LIBRARY(linkdate STATIC EXCLUDE_FROM_ALL linkdate.c)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main linkdate)
ADD_CUSTOM_COMMAND(
TARGET main
PRE_LINK
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/linkdate.c.in
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
 --target linkdate)

This rebuilds the target linkdate - a static library containing the
desired timestamp - just before the main target is linked against it.
Thus, the problems you mentioned should be solved except for #1 which
can not be done in a platform-independent manner at the moment, AFAIK.

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] *.c compiled with C compiler after clearing CMAKE_C_SOURCE_FILE_EXTENSIONS

[Michael Hertling]

On 10/12/2010 03:26 PM, Jed Brown wrote:
> I realize this may look silly, but after
> 
>   list (REMOVE_ITEM CMAKE_C_SOURCE_FILE_EXTENSIONS c)
>   list (APPEND CMAKE_CXX_SOURCE_FILE_EXTENSIONS c)
> 
> source files matching *.c are still compiled with the C compiler (not C++).
>  Is there a way to get *.c compiled with the C++ compiler?
> 
> (cmake-2.8.2)

You could set the source file property LANGUAGE to CXX.

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] Recompiling source file multiple times

[Michael Hertling]

On 10/11/2010 10:04 PM, Belcourt, Kenneth wrote:
> Hi,
> 
> I did a quick scan looking for this but didn't see this mentioned in  
> the FAQ.
> 
> Is there a documented process for compiling a single source file  
> multiple times?  For example, the UMFPACK library need to compile most  
> source files at least twice with a different set of defined macros for  
> each build.  They often use -DDINT for one compilation and then  
> undefined -DDINT and define -DDLONG.  Anyone know a good way to handle  
> this?

A source file is compiled individually for each target it becomes part
of, so the definitions can by applied per target as target properties.
Furthermore, you could create symlinks to the concerned sources which
can be used to apply different definitions as source file properties:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MULTCOMP C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
ADD_LIBRARY(f1 SHARED f.c)
ADD_LIBRARY(f2 SHARED f.c)
SET_TARGET_PROPERTIES(f1 PROPERTIES COMPILE_DEFINITIONS T1)
SET_TARGET_PROPERTIES(f2 PROPERTIES COMPILE_DEFINITIONS T2)
ADD_CUSTOM_COMMAND(OUTPUT ff.c
COMMAND ${CMAKE_COMMAND} -E create_symlink f.c ff.c DEPENDS f.c)
SET_SOURCE_FILES_PROPERTIES(ff.c PROPERTIES COMPILE_DEFINITIONS FF)
ADD_LIBRARY(ff SHARED ff.c)

The sole source file f.c is compiled with -DT1 for target t1, -DT2 for
target t2 and - as symlink ff.c - with -DFF for target ff. You could
even consider to link or copy entire directories of source files in
order to apply different definitions as directory properties.

'hope that helps.

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] how to define current working directory of command line tool

[Michael Hertling]

On 10/11/2010 11:20 AM, Jochen Wilhelmy wrote:
> 
>>> Hi!
>>>  
>>> Is it possible to define the current working directory of a command line
>>> tool
>>> that is built with cmake? since the build is usually out-of-source I 
>>> have
>>> to set the current working directory in the ide, e.g visual studio or
>>> xcode. more convenient would be to set it in cmake.
>>>
>>>
>>>  
>> Do you mean in add_custom_command()/add_custom_target() ?
>> Both have an optional WORKING_DIRECTORY argument.
>>
>>
>>
> no, i mean add_executable. when I build and start the directory I'd like 
> to set the
> working directory that the executable is started in.
>
> -Jochen
>
>  
 I think that you have a misconception with respect to the concept of 
 "working directory".

 In a Unix-style environment, the "working directory" is determined by the 
 "shell" command line interpreter. The actual value is determined only at 
 execution-time. It is not something "built-in" to the executable.


>>> No, I mean this very unix-style working directory. Of course this is only a 
>>> debug setting, i.e. it does not influence the
>>> build result. But if I write a command line tool, e.g. a copy, then I have 
>>> some test files to copy and need some arguments
>>> for the copy tool to tell it which files to copy. Therefore it is possible 
>>> to set the working directory and command line
>>> arguments in an ide (visual studio or xcode). For xcode there is even the 
>>> effect that after cmake runs the current
>>> setting is lost which is not the case for visual studio since these 
>>> settings are stored in a separate file.
>>>
>>> -Jochen
>>>  
>> Are you trying to run the executable with ADD_TEST? In that case the working 
>> directory is always CMAKE_CURRENT_BINARY_DIR. If you need to change it, 
>> create a wrapper script (you can do so using the CMake language in order to 
>> not depend on any other interpreter).
>>
> no, just add_executable and then starting the target in debug mode 
> inside the ide. but maybe add_test is the solution to my
> problem, i have to look at it. is this for starting an executable with 
> some command line arguments?

You might consider to use ADD_CUSTOM_COMMAND(TARGET ...), e.g.:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CWD C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "
#include 
#include 
int main(void)
{
char cwd[1000];
getcwd(cwd,sizeof cwd);
printf(\"CWD: %s\\n\",cwd);
return 0;
}
")
ADD_EXECUTABLE(main main.c)
ADD_CUSTOM_COMMAND(TARGET main
POST_BUILD
COMMAND main
WORKING_DIRECTORY /var/tmp)

This runs the executable "main" each time after it has been (re)built
from within the working directory "/var/tmp" - adapt for non-*nices.

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] What does find_package(COMPONENTS) do? and

[Michael Hertling]

On 10/06/2010 10:47 PM, Stephen Kelly wrote:
> Hi,
> 
> The documentation says
> 
>> A package-specific list of components may be listed after the REQUIRED 
>> option or after the COMPONENTS option if no REQUIRED option is given. 
> 
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
> 
> But it doesn't say why you would want to do that. At first I thought it was 
> to specify that only the components specified would be used to fill cmake 
> variables. However, find_package(Qt COMPONENTS QtCore) also results in 
> ${QT_QTGUI_LIBRARY} being defined for example. [...]

Which variables do you aim at? The cached ones, e.g. XXX_YY_LIBRARY, or
the non-cached ones, e.g. XXX_LIBRARIES? IMO, it is alright to fill the
formers regardless if the corresponding component has been requested or
not, although there could be reasons not to do so. Anyway, the latters
should be provided with values for the explicitly requested components
only; otherwise, FIND_PACKAGE()'s COMPONENTS option doesn't make sense.
When including the QT_USE_FILE, the find module of Qt4 behaves in this
manner, but only the QT_LIBRARIES variable is provided; the component-
specific definitions like QT_GUI_LIB and the include directories are
just enabled without being made accessible via variables, cf. [1].

> [...] So then I thought maybe the 
> semantic is that if one of the components can not be found, the find_package 
> fails. So I tried find_package(Qt REQUIRED QtCore QtDoesNotExist) which 
> works without error.

In my understanding, this behaviour is wrong, indeed, since it makes
the REQUIRED flag useless, or in other words: After having requested
the components as REQUIRED, one strongly dislikes the need to check
whether they've actually been found. However, there's a fundamental
limitation of FIND_PACKAGE() w.r.t. optional components: They can't
be requested along with required ones as a find module has no means
to distinguish them, cf. [2].

> What am I missing?

Basically nothing, but the recommended behaviour of components-aware
find modules should be elaborated better, and the Qt ones are even a
bit special. Questions which may need a clarification are, e.g.:

- Lookup of components that aren't requested by the user?
- Meaning of the REQUIRED flag in regard to missing components?
- Standardization of component lookup results? FPHSA() doesn't suit.
- Do multi-component FIND_PACKAGE() calls work accumulatively, i.e. do
  FIND_PACKAGE(XXX COMPONENTS YY1) and FIND_PACKAGE(XXX COMPONENTS YY2)
  end up with XXX_LIBRARIES=="${XXX_YY1_LIBRARY} ${XXX_YY2_LIBRARY}",
  or are the results of the former overwritten by the latter?
- Guidelines concerning "use files" like QT_USE_FILES.

> The reason I ask is that I finally figured out why the tests in my library 
> needed to be linked to QtGui, even though it only uses QtCore.
> 
> The reason is that find_package(Qt) causes QT_GUI_LIB to be defined. Which 
> in turn causes QTEST_MAIN to be defined to expand to use QApplication 
> instead of QCoreApplication as it is if QT_GUI_LIB is not defined.
> 
> http://qt.gitorious.org/qt/qt/blobs/4.7/src/testlib/qtest.h
> 
> find_package(Qt REQUIRED QtCore QtScript) does not cause QT_GUI_LIB to be 
> defined. However, some of my targets do need QtGui, so I should specify it, 
> right? 

Not necessarily: You could try to issue, e.g., FIND_PACKAGE(Qt4) without
including the QT_USE_FILE, rely on FindQt4.cmake to detect all available
Qt components and use the latters' specific variables explicitly, i.e.:

ADD_DEFINITIONS(-DQT_GUI_LIB)
INCLUDE_DIRECTORIES(${QT_QTGUI_INCLUDE_DIR})
...
TARGET_LINK_LIBRARIES(... ${QT_QTGUI_LIBRARY})

So, you can control if, when and for what QT_GUI_LIB is defined since
it's the QT_USE_FILE which enables QT_GUI_LIB generally if QtGui is
mentioned among the components of the FIND_PACKAGE(Qt4 ...) call.

> So if I do specify it I'll end up having QT_GUI_LIB defined when building my 
> unit tests. I could remove_definitions(-DQT_GUI_LIB), but apart from being a 
> BadHack(tm), it causes my unit tests which *do* require QtGui to fail at 
> runtime because they create QWidgets and by undeffing QT_GUI_LIB I build 
> them to use QCoreApplication instead of QApplication (Not allowed in Qt), so 
> the tests fail at runtime.
> 
> http://gitorious.org/grantlee/grantlee/blobs/0.1/tests/CMakeLists.txt
> 
> Is there a solution to all this? What is the point of COMPONENTS if it has 
> no effect on what I can include or link to? Is it possible to link some of 
> my tests to QtGui but not all of them and still have them all pass? Do I 
> need to just link my core tests to QtGui and use QApplication and quit my 
> complaining?

As I can see from your CMakeLists.txt, you do not use QT_USE_FILE's
results, particularly QT_LIBRARIES, so it should be possible to omit
its inclusion and, instead, define QT_GUI_LIB et al. per source file
or target. As an alternative, you can follow Andreas' suggestion and
divide your targets into GUI-depende

Re: [CMake] How to depend on an ExternalProject

[Michael Hertling]

On 10/08/2010 12:50 PM, Michael Wild wrote:
> 
> On 8. Oct, 2010, at 12:13 , Rolf Eike Beer wrote:
> 
>>>
>>> On 8. Oct, 2010, at 10:50 , Rolf Eike Beer wrote:
>>>
 Hi,

 I have a problem with ExternalProject and how to depend on that. I'm not
 absolutely sure I got the CMakeLists.txt right, so I first ask here
 before
 filing a bug report.

 The idea is like this: we have an project that generates a couple of
 files. In a special configuration of another project we need those files
 as input for a special build step. Those step will take those files,
 mangle them and will generate a source file at the end. This is then
 added
 as usual to a library (in my example below to a executable, but that
 doesn't matter). When I run the example below I get:

 [ 80%] Built target Subdir_Build
 make[2]: *** No rule to make target `Subdir_Build', needed by `main.c'.
 Stop.
>>
>> [...]
>>
>>> Subdir_Build is a top-level target, and the custom-command can only depend
>>> on files. You need to add a custom target that depends on main.c and then
>>> add a dependency of that custom target on Subdir_Build.
>>
>> The documentation of add_custom_command has this sentence:
>>
>> If DEPENDS specifies any target (created by an ADD_* command) a
>> target-level dependency is created to make sure the target is built
>> before any target using this custom command.
>>
>> So if I can't depend on a target this is extremely confusing. Even worse:
>> the dependency itself _works_, i.e. Subdir_Build always get's properly
>> build before the depending target. But even then depending target fails.
>>
>> Eike
> 
> Does it work with the custom target? Because that's how it works for me. But 
> I agree that either the documentation is wrong or there is a bug...

AFAIK, the external project is incorporated as a custom target, and
custom targets are not suited as prerequisites of a custom command's
output whereas ordinary targets, i.e. executables and libraries, are:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CUSTOMDEPENDS C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
ADD_LIBRARY(f SHARED f.c)
ADD_CUSTOM_TARGET(t ${CMAKE_COMMAND} -E echo "Building custom target t")
ADD_CUSTOM_COMMAND(
OUTPUT timestamp1
COMMAND ${CMAKE_COMMAND} -E touch timestamp1
DEPENDS f
)
ADD_CUSTOM_COMMAND(
OUTPUT timestamp2
COMMAND ${CMAKE_COMMAND} -E touch timestamp2
DEPENDS t
)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main1 EXCLUDE_FROM_ALL main.c timestamp1)
ADD_EXECUTABLE(main2 EXCLUDE_FROM_ALL main.c timestamp2)

On *nix, I can see main1 getting built, and it gets rebuilt along f and
timestamp1 if f.c is touched. In contrast, building main2 fails due to
the missing rule for the custom target t although t can be built on the
direct way. Of course, you can succeed with an additional custom target
in junction with explicitly declared dependencies, but IMO, too, this
shortcoming of custom targets w.r.t. custom commands should be
mentioned in the documentation - or considered as a bug.

Recently, IIRC, I've seen a similar configuration work with a custom
target declared in another CMakeLists.txt as the one containing the
depending custom command, but currently, I can't reproduce it. :(
Perhaps, the CMake developers can give us a hint in this matter.

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] Get configuration-dependant LOCATION property

[Michael Hertling]

On 10/04/2010 11:15 PM, Mateusz Loskot wrote:
> On 04/10/10 14:24, Michael Hertling wrote:
>> On 10/04/2010 10:53 AM, Mateusz Loskot wrote:
>>> On 04/10/10 07:33, J Decker wrote:
>>>> CMAKE_INSTALL_CONFIG_NAME I don't know if there's a simple flag like
>>>> 'project supports multiple targets' so I have an if(MSVC) set(
>>>> MULTI_TARGET) endif()   if( MULTI_TARGET ) Install( targets ...
>>>> ${CMAKE_INSTALL_CONFIG_NAME ) else() isntall( ... ${CMAKE_BUILD_TYPE}
>>>
>>>
>>> I need it before firing up install procedures.
>>> I build.
>>> I run tests (here I need to know location of build output per target).
>>
>> Have you already taken a look at ADD_TEST()'s generator expressions like
>> $? AFAIK, they've been introduced quite exactly to
>> meet requirements such as yours.
> 
> Hmm, I've seen this expressions, but I'm not sure how it can be useful
> because the expressions are used to generate test input.
> 
> My problem is about getting property to generate environment
> for test before it is executed:
> 
> In one subtree of my sources, I have mylib target building mylib.dll
> In another subtree, I have test. Next, I build and run test:
> 
> add_executable(mytest test.cpp)
> 
> target_link_libraries(mytest mylib_import.lib)
> 
> add_test(mytest ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/mytest)
> 
> set_tests_properties(mytest PROPERTIES
>   ENVIRONMENT "PATH=c:\path\to\dir\with\mylib.dll\")
> 
> I need to figure out this: "c:\path\to\dir\with\mylib.dll\"

You might consider to use a script as a test driver which takes
the desired path and the test executable as parameters, e.g.

ADD_TEST(mytest
testdriver $ $)

with testdriver setting the PATH and executing mytest.

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] [windows][fortran][Unix Makefiles] Bug with CMAKE_AR expansion

[Michael Hertling]

On 10/04/2010 02:14 PM, Maik Beckmann wrote:
> The problem seem to be triggered the fact that the toplevel
> CMakeLists.txt (
> http://gitorious.org/hdf5/hdf5-v18/blobs/master/CMakeLists.txt )
> contains
>   PROJECT (HDF5 C CXX)
> and another CMakeLists.txt in a subdirectory (
> http://gitorious.org/hdf5/hdf5-v18/blobs/master/hl/fortran/CMakeLists.txt
> )
>   PROJECT(HDF5_HL_F90 C CXX Fortran)
> because the problem vanishes when I add Fortran to the list of
> languages in the toplevel CMakeLists.txt
>   PROJECT (HDF5 C CXX Fortran)
> 
> This workaround works for me, but is of course not a solution for the
> maintainer of  http://gitorious.org/hdf5/hdf5-v18 .

FYI: Recently, there has been another issue which makes it necessary to
enable Fortran in the top-level PROJECT() rather than in a sub-project
of a mixed-language configuration: [1]. Maybe, these two issues are
interrelated and can be traced back to the same origin.

Regards,

Michael

[1] http://www.mail-archive.com/cmake@cmake.org/msg31690.html
___
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] Get configuration-dependant LOCATION property

[Michael Hertling]

On 10/04/2010 10:53 AM, Mateusz Loskot wrote:
> On 04/10/10 07:33, J Decker wrote:
>> CMAKE_INSTALL_CONFIG_NAME I don't know if there's a simple flag like
>> 'project supports multiple targets' so I have an if(MSVC) set(
>> MULTI_TARGET) endif()   if( MULTI_TARGET ) Install( targets ...
>> ${CMAKE_INSTALL_CONFIG_NAME ) else() isntall( ... ${CMAKE_BUILD_TYPE}
> 
> 
> I need it before firing up install procedures.
> I build.
> I run tests (here I need to know location of build output per target).

Have you already taken a look at ADD_TEST()'s generator expressions like
$? AFAIK, they've been introduced quite exactly to
meet requirements such as yours.

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] Following dependencies through generated header file

[Michael Hertling]

On 10/03/2010 02:01 AM, Óscar Fuentes wrote:
> Michael Hertling 
> writes:
> 
>>> It would be very convenient to inspect the header files referenced from
>>> `zoo.cpp' and associate them with `bar.inc', so when some of those
>>> header files are touched `bar.inc' (and hence `foo.cpp') is
>>> automatically re-built.
>>>
>>> Is this possible?
>>
>> Yes, with a bit of trickiness:
> 
> [snip]
> 
> Thanks for idea, Michael, sounds interesting, although having to use a
> library is an incovenience, mainly for the people who use IDEs. (The
> project I'm working on would need more than 20 such libraries)

Yes, that's annoying. AFAIK, you cannot hook into CMake's built-in
dependency scanner for the time being, so it's quite difficult to
achieve your goal in a convenient manner, but perhaps there's a
possibility to do better than using a dummy library target:

Place the following files in your CMAKE_SOURCE_DIR:

foo.cpp:
#include "bar.inc"

zoo.cpp:
#include "zoo.h"

zoo.h:
#define ZOO_H

scandeps.cmake:
EXECUTE_PROCESS(COMMAND gcc -M ${SOURCE} OUTPUT_VARIABLE DEPS)
STRING(REGEX REPLACE "^.*: " "" DEPS ${DEPS})
STRING(REGEX REPLACE " \n " "\n" DEPS ${DEPS})
FILE(WRITE ${OUTPUT}.in "SET(${VARIABLE}\n${DEPS})\n")
CONFIGURE_FILE(${OUTPUT}.in ${OUTPUT} COPYONLY)

CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(GENDEP CXX)
IF(NOT EXISTS ${CMAKE_BINARY_DIR}/deps.cmake)
FILE(WRITE ${CMAKE_BINARY_DIR}/deps.cmake "")
ENDIF()
INCLUDE(${CMAKE_BINARY_DIR}/deps.cmake)
MESSAGE("DEPS: ${DEPS}")
INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR})
ADD_LIBRARY(foo.aux SHARED EXCLUDE_FROM_ALL foo.cpp bar.inc)
SET_TARGET_PROPERTIES(foo.aux PROPERTIES OUTPUT_NAME foo)
ADD_CUSTOM_COMMAND(OUTPUT bar.inc
COMMAND ${CMAKE_COMMAND} -E touch bar.inc DEPENDS ${DEPS})
ADD_CUSTOM_TARGET(foo ALL
COMMAND ${CMAKE_COMMAND}
-DSOURCE=${CMAKE_SOURCE_DIR}/zoo.cpp
-DOUTPUT=${CMAKE_BINARY_DIR}/deps.cmake
-DVARIABLE=DEPS
-P ${CMAKE_SOURCE_DIR}/scandeps.cmake
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
 --target foo.aux)

The basic idea is the following: The custom target foo invokes a script
scandeps.cmake which uses an external dependency scanner - here, gcc's
-M facility - to get the files zoo.cpp depends on. This list is tweaked
a bit and written to deps.cmake as a CMake SET() command for a variable
DEPS; the deps.cmake is included in the CMakeLists.txt. Finally, target
foo builds the actual library as target foo.aux using CMake's --build
option. During the initial CMake run, bar.inc receives no dependencies,
but the subsequent build will generate deps.cmake, and as this file is
included in CMakeLists.txt, the final "cmake --build" command will re-
run CMake before building foo.aux - then with the correct and updated
dependencies of bar.inc. The same holds if bar.inc's dependencies are
changed later, i.e. the gcc -M output sometime differs. Additionally,
scandeps.cmake uses CONFIGURE_FILE() for the generation of deps.cmake
in order to avoid unnecessary CMake runs. This approach works on *nix
with Makefiles, but I don't know if it's suitable for other generators
or IDE's.

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] QT4 and MOC

[Michael Hertling]

On 10/02/2010 09:07 AM, Laszlo Papp wrote:
> Hi,
> 
> I wrote a helloworld class, source and header file for instance which
> is basically moc related class with Q_OBJECT macro. I do not know why
> I must use qt4_wrap_cpp(helloworld.h) beside
> qt4_automoc(helloworld.cpp).

There's no need to use both.

> I always thought that qt4_automoc can recognize it. I would like to
> avoid the moc file include at the end of my source line. I would like
> to link that generated moc at linkage time, mostly.

With QT4_AUTOMOC(), you must include the generated moc files in your
sources, but with QT4_WRAP_CPP(), you can do, e.g., the following:

SET(HEADERS helloworld.h)
SET(SOURCES main.cpp helloworld.cpp)
QT4_WRAP_CPP(SOURCES ${HEADERS})
ADD_EXECUTABLE(main ${SOURCES} ${HEADERS})
TARGET_LINK_LIBRARIES(main ${QT_LIBRARIES})

So, the generated moc files are compiled and linked along with the
usual source files, and it's not necessary to include them anywhere.

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] Following dependencies through generated header file

[Michael Hertling]

On 10/01/2010 10:56 PM, Óscar Fuentes wrote:
> A file `foo.cpp' has this:
> 
> #include "bar.inc"
> 
> `bar.inc' is a generated file, and is marked as such. It is generated
> processing a file `zoo.cpp' with an utility executed through a custom
> command.
> 
> It would be very convenient to inspect the header files referenced from
> `zoo.cpp' and associate them with `bar.inc', so when some of those
> header files are touched `bar.inc' (and hence `foo.cpp') is
> automatically re-built.
> 
> Is this possible?

Yes, with a bit of trickiness:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(GENDEP CXX)
FILE(WRITE ${CMAKE_BINARY_DIR}/foo.cpp "#include \"bar.inc\"\n")
FILE(WRITE ${CMAKE_BINARY_DIR}/zoo.cpp "#include \"zoo.h\"\n")
FILE(WRITE ${CMAKE_BINARY_DIR}/zoo.h "#define ZOO_H\n")
ADD_LIBRARY(zoo SHARED zoo.cpp)
ADD_LIBRARY(foo SHARED foo.cpp bar.inc)
ADD_CUSTOM_COMMAND(OUTPUT bar.inc
COMMAND ${CMAKE_COMMAND} -E touch bar.inc DEPENDS zoo.cpp zoo)

So, zoo.cpp includes zoo.h, the helper target zoo is compiled from
zoo.cpp, and the custom command which generates bar.inc depends on
zoo.cpp as desired, but on the zoo target, too - that's the crucial
moment: If zoo.h is touched, zoo is rebuilt, but the custom command
runs also since one of its dependencies is a library and newer than
its output. AFAIK, files intended to be subject of CMake's built-in
dependency checking must be mentioned in a target's sources, hence
the necessity of the auxiliary zoo target to trigger the generation
of bar.inc if one of zoo.cpp's included headers change.

'hope that helps.

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] Build several libraries with different compilation flags

[Michael Hertling]

On 10/01/2010 05:10 PM, pellegrini wrote:
> Hi Ryan,
> 
> Yes, that might be the solution if I wanted to change the compiler flags 
> for the whole library but in my case, that is not on the whole
> library that I want to apply a new set of compiler flags but only on a 
> small number of files.

You could use symbolic links in junction with source properties:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(SYMLINKSOURCE C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f1.c "void f(void){}\n")
ADD_LIBRARY(l1 SHARED f1.c)
ADD_CUSTOM_COMMAND(OUTPUT f2.c
  COMMAND ${CMAKE_COMMAND} -E create_symlink f1.c f2.c)
SET_SOURCE_FILES_PROPERTIES(f2.c PROPERTIES COMPILE_FLAGS "-O0")
ADD_LIBRARY(l2 SHARED f2.c)

So, the l{1,2} targets are compiled from the same source but with
different flags, and the latters can be specified per source file.

Regards,

Michael

> Ryan Pavlik a écrit :
>>  Look at the target properties instead of the source file properties.
>>
>> Ryan
>>
>> On 10/01/2010 08:27 AM, pellegrini wrote:
>>> Hello everybody,
>>>
>>> I would like to build two libraries that contain the same files but 
>>> with a slightly different set of compilation flags
>>> from one library to another. This within the same makefile. I was 
>>> thinking about an approach such as:
>>>
>>> add_library(my_lib1, STATIC, src_files ...)
>>> set_source_files_properties(file1, file2 ... PROPERTIES COMPILE_FLAGS 
>>> ...)
>>> add_library(my_lib2, STATIC, src_files ...)
>>> set_source_files_properties(file1, file2 ... PROPERTIES COMPILE_FLAGS 
>>> ...)
>>>
>>> does cmake sensitive to the order of these instruction ?
>>>
>>> thank you very much
>>>
>>> Eric
___
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] Separate CXXFLAGS and LDFLAGS

[Michael Hertling]

On 10/01/2010 03:55 PM, Marek Szuba wrote:
> Hello,
> 
> How can one define C++ compiler flags which are used ONLY at compile time?
> Traditional LDFLAGS appear to clearly map to CMAKE_xxx_LINKER_FLAGS, however
> CMAKE_CXX_FLAGS work differently from what I would like - they are passed to
> both the compiler and the linker.

...and that's possibly necessary:



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] How to specify -fpic ?

[Michael Hertling]

On 09/29/2010 06:25 PM, David Aldrich wrote:
> Hi
> 
> My C++ code consists of an executable and several shared libraries.
> 
> With my CMake build files, I find that the executable fails to load the 
> shared libraries ( the dlopen() call results in error 'undefined symbol...' ).
> 
> The software works fine under our production build system that uses manually 
> coded makefiles.
> 
> I notice that the production system linker command invokes -fpic, while CMake 
> uses -fPIC. I am wondering if that is the reason.
> 
> I set the compile flags with:
> 
> set( CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG -Wall -m64" )
> 
> How can I replace -fPIC with -fpic in CMake please?

STRING(REGEX REPLACE "-fPIC" "-fpic" CMAKE_SHARED_LIBRARY_CXX_FLAGS
${CMAKE_SHARED_LIBRARY_CXX_FLAGS})

Is this option the only difference of the link commands? Do the compile
commands differ, too? Are there any options in the compile commands
which should also be present in the link commands but are missing?

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] embedding lib into a shared object

[Michael Hertling]

On 09/29/2010 12:26 PM, Ovanes Markarian wrote:
> Hello *,
> 
> I have some library available as a Linux lib file. Now I need to create a
> shared object (actually a MODULE in terms of CMake) out of this lib. The
> module is later on loaded using the dlopen-API function.
> 
> I created a sample project with
> 
> /
> +-- testlib
> +-- so
> 
> 
> testlib - consists of a single cpp file haveing a global variable and a
> function returning it.
> 
> CMake script:
> CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
> 
> PROJECT(testlib CXX)
> 
> add_library(testlib STATIC functions.cpp)
> 
> 
> so - consists of a cpp file and links against testlib.
> 
> CMake script:
> CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
> 
> PROJECT(so CXX)
> 
> add_library(so MODULE main.cpp)
> target_link_libraries(so testlib)
> set_target_properties (so PROPERTIES VERSION 1.0 LINKER_LANGUAGE CXX)
> 
> and the Root CMakeLists.txt which should build both:
> 
> CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
> 
> PROJECT(dll_test CXX)
> 
> add_subdirectory(lib)
> add_subdirectory(so)
> add_dependencies(so lib)
> 
> 
> Now my problem is that after the build I can find the symbols from
> functions.cpp in the lib file using the nm tool. But these symbols are not
> part of the so. How can I force them to be part of the so-Module?

man ld:

[...]
--whole-archive
For each archive mentioned on the command line after the --whole-
archive option, include every object file in the archive in the
link, rather than searching the archive for the required object
files. This is normally used to turn an archive file into a
shared library, forcing every object to be included in the
resulting shared library. This option may be used more than once.

Two notes when using this option from gcc: First, gcc doesn’t know
about this option, so you have to use -Wl,-whole-archive. Second,
don’t forget to use -Wl,-no-whole-archive after your list of
archives, because gcc will add its own list of archives to your
link and you may not want this flag to affect those as well.
[...]

E.g., you can use the LINK_FLAGS target property to enable this option,
and don't forget -fPIC and 'extern "C"' for functions.cpp's dlopening.

Besides, the ADD_DEPENDENCIES() is not necessary because of the
TARGET_LINK_LIBRARIES(), and wouldn't it be worth considering to
compile the dl-suitable module from the static library's sources?

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] How to set compiler flags?

[Michael Hertling]

On 09/28/2010 05:35 PM, David Aldrich wrote:
> Hi
> 
> I am writing CMakeLists.txt files for my C++ application. Initially I set the 
> C++ compiler flags by setting CMAKE_CXX_FLAGS:
> 
> set( CMAKE_CXX_FLAGS "-Wall -m64 -O3 " )
> 
> Then I realised that those flags get passed to the linker as well, which 
> seemed a bit untidy. [...]

But possibly necessary:



et seq.

> [...] So I now use add_definitions instead:
> 
> add_definitions( "-Wall -m64 -O3" )
> 
> Is there a better way of doing this?

Don't do this at all, and adhere to the flags.

> My CMakeLists.txt files only handle a release build currently. If you could 
> give me a hint for how to go on to add a debug build option, I would be 
> grateful.

Doesn't the DEBUG variant of the flags, e.g. CMAKE_CXX_FLAGS_DEBUG, and
other related variables - perhaps in connection with CMAKE_BUILD_TYPE -
work for you?

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