Re: [CMake] List all packages

[Lectem]

Thanks for the answers

You can visualize dependencies between targets with Graphvis:

This is not really what I need, I want to see all the available packages 
installed on my PC (package registry, Find_XXX modules …), not the hierarchy of 
targets in a cmakelists.txt


Hey,

As far as I know there is no such mechanism. But you can write a little script 
f.e. in python (or cmake itself) which can do that, because it is just a simple 
file search.

Greetings
Tonka

Aw that’s sad, I’d like to avoid writing my own script because there are a lot 
of things to take into account based on the platform.
It would be better if I could invoke cmake from the commandline to do this.

Should such feature-request be sent to the mailing list or gitlab ?




De : Konstantin Podsvirov
Envoyé le :dimanche 13 janvier 2019 11:23
À : Cmake Mailing List
Objet :Re: [CMake] List all packages

Hello, Lectem.

11:43, 13 January 2019 г., Lectem :
 
Hi,
 
Is there a way to list all the packages (both config files and find-modules) 
that find_package could find ?
Could we even imagine this would also permit to list the variables and targets 
created in it ?
I think that would be a very helpful to have for debugging find_package, 
especially when you don’t have access to the system having issues (user bug 
reports for example).

Cheers,
Lectem

You can visualize dependencies between targets with Graphvis:

https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/Graphviz

--
With regards,
Konstantin Podsvirov

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

[CMake] List all packages

[Lectem]

Hi,

Is there a way to list all the packages (both config files and find-modules) 
that find_package could find ?
Could we even imagine this would also permit to list the variables and targets 
created in it ?
I think that would be a very helpful to have for debugging find_package, 
especially when you don’t have access to the system having issues (user bug 
reports for example).


Cheers,
Lectem
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] pkg-config file format versus CMake packages

[Lectem]

Hi,
I’ll start by saying that I love the fact we’re now talking about a common 
representation of packages !

➢ The reason I say this is that extending pkg-config seems like it would help 
adoption rather then creating a completely new format. There is already a good 
portion of open source projects that already support pkg-config, so tweaking 
them to support more complicated scenarios seems easier than converting 
everything to a new format.

I’m not very familiar with pkg-config (working more in the Windows world) so 
excuse me if I’m wrong.

>From what I remember it is very basic and relies on compiler flags being the 
>same everywhere (ie gcc-like flags), and does not provide any information 
>about things such as ABI, C-runtime Library used (arguably could be 
>represented as a package ?). As far as I know, it assumes that the libraries 
>are always compiled with the same compiler on the same system, hence has no 
>knowledge of compatibility between compiler versions. 
As you mentionned, it currently relies on -l for both libraries and linker 
flags, which would need to be changed.

➢ so tweaking them to support more complicated scenarios seems easier than 
converting everything to a new format.

Wouldn’t that create more confusion ? I fear it’d end up as a python2 python3 
issue, where both versions look alike but are incompatible.


Have a nice Week-end,
Lectem
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [cmake-developers] include directories per source file

[Lectem]

(edited the subject)
> Did you check these?
> https://cmake.org/cmake/help/v3.10/command/target_include_directories.html
> https://cmake.org/cmake/help/v3.10/command/target_sources.html
Yes I’m very well aware of those commands, but they do not achieve what I 
described, as it populates target properties, not source file properties.
Also target_sources can only be used to conditionally link targets or propagate 
source files needed for target that links the library (such as .natvis files), 
which is not what I want here.

Bests,
Lectem

De : Jano Svitok
Envoyé le :samedi 2 décembre 2017 13:38
À : Lectem
Cc : cmake-developers@cmake.org
Objet :Re: [cmake-developers] (no subject)

On Sat, Dec 2, 2017 at 10:45 AM, Lectem <lec...@gmail.com> wrote:
Hi,
 
I’m hurting an issue trying to hide dependencies from files that do not need 
those.
For example, I have a library that helps me decode some file, but I don’t want 
this library headers to be available for every .cpp in my library but one.
 
For example what one may do is the following :
 
#-
add_library(mylib foo.cpp bar.cpp)
target_link_libraries(mylib PRIVATE libonlyusefulforfoo)
#-
 
It works fine, but now bar.cpp can also include headers from 
libonlyusefulforfoo.
So what I tried was to use object libraries, but it has many disadvantages :
• I now have to duplicate dependencies for the object library and mylib if they 
have include directories requirements or compile flags in common
• An object library is a target… and I don’t want to add one target per file 
that has special include directories
• An object library shows in IDEs, while I’d like the .cpp files to stay in the 
same project. In visual the obj will be in my library but this is not practical.
I thought about source files properties, but unfortunately they do not support 
include directories, so here is my question :
 
TL ;DR
Would it be possible/difficult to have a PRIVATE_INCLUDE_DIRECTORIES property 
added for source files ? 
We already have COMPILE_FLAGS so why not include directories ?
 
I know we can set include directories per directory, but I don’t think that 
putting single .cpp files in seperate headers is good.
 
Thanks,
Lectem

Did you check these?

https://cmake.org/cmake/help/v3.10/command/target_include_directories.html
https://cmake.org/cmake/help/v3.10/command/target_sources.html
Jano

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] (no subject)

[Lectem]

Hi,

I’m hurting an issue trying to hide dependencies from files that do not need 
those.
For example, I have a library that helps me decode some file, but I don’t want 
this library headers to be available for every .cpp in my library but one.

For example what one may do is the following :

#-
add_library(mylib foo.cpp bar.cpp)
target_link_libraries(mylib PRIVATE libonlyusefulforfoo)
#-

It works fine, but now bar.cpp can also include headers from 
libonlyusefulforfoo.
So what I tried was to use object libraries, but it has many disadvantages :
- I now have to duplicate dependencies for the object library and mylib if they 
have include directories requirements or compile flags in common
- An object library is a target… and I don’t want to add one target per file 
that has special include directories
- An object library shows in IDEs, while I’d like the .cpp files to stay in the 
same project. In visual the obj will be in my library but this is not practical.
I thought about source files properties, but unfortunately they do not support 
include directories, so here is my question :

TL ;DR
Would it be possible/difficult to have a PRIVATE_INCLUDE_DIRECTORIES property 
added for source files ? 
We already have COMPILE_FLAGS so why not include directories ?

I know we can set include directories per directory, but I don’t think that 
putting single .cpp files in seperate headers is good.

Thanks,
Lectem
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Make it easier for beginners

[Lectem]

Hi guys.

You've probably seen me whining a bit here and there about why CMake is hard to 
get for begginers, 
and thanks to Ruslo pushing me to it, I finally got the motivation to be 
involved and contribute to CMake.
I hope this mail can be the beginning of a thought on the CMake ecosystem, and 
not seen as a rant.

I'd like to discuss a few issues and learning barriers I've heard in the 
previous years concerning CMake.
Those problems were even more pointed out recently when Boost decided to switch 
to cmake.
Most of the time, people will tell you stuff like this (note that I'm not 
inventing those, as most were told to me by co-workers) :

- "it is too hard to know what I should do, or how to do it right"
- "Many articles are out there, none agree on what to do and the documentation 
is just an API reference, not a real documentation"
- "Based my CmakeLists.txt on the wiki, and now people tell me it's bad 
practice"
- "I don't get why it's not finding my stuff, it's frustrating"
- "I managed to get a simple program running, but as soon as tried to add more 
stuff, nothing was working or I didn't understand the docs"
... And the list goes on.

>From my point of view, it mostly comes from a misconception of what CMake now 
>is and the fact it is hard to learn.
In a sense, it's basicly the same problem as C++. 
CMake can be easy, but is seen as hard by some people because it has many 
features and ways to express the same thing, and that many people write 
CMakeLists.txt that do not "embrace modern CMake".

So I'd like to make it easier for these people to learn CMake, and for that I 
need some pointers and the opinion of the current developpers.
I'll make this a list of questions / proposals on which I need feedback, and 
try to explain my reasons behind it.

Question : Would it possible to delete the wiki, or reset/reopen it ?
Reason: The wiki is full of old stuff, but we can't register to edit stuff.  
Still, people willing to learn will end up visiting it, thinking it gives good 
advice. "How could it not ? It's the official wiki". At the very least I wish 
we could add a big red message stating it is outdated and not updated anymore.


Question: Would it be ok to add tutorials to the documentation ?
Reason: That's where most people will start with. Diving in the CMake 
documentation is hard for beginners.  For example, understanding transitive 
properties requires that you read most of cmake-buildsystem, which is a lot to 
digest at once. A tutorial would help people understanding how to use it and 
more importantly why they should use it.


Question: Add examples (in link with the tutorials) ?
Reason : Mostly the same as the previous one, having examples can help people 
with a quickstart and agree on what is the "latest" command/feature to use for 
X/Y/Z.

Question: Can we add "Added in / API last updated" fields ? I'm not familiar 
enough with Sphynx yet to know how we could change the template for this. Or 
perhaps just add it as text in the rst?
Reason: It is hard to know in what version some functionalities are added, and 
not everybody can afford to require the latest CMake version (though it would 
be nice). It would be nice to have this at least for new features in the next 
version

I hope that little by little we will make CMake easier to use for the 
community, and to this end I'm ready to spend time updating the documentation, 
errors and write some tutorials / examples.
I truely believe that it is as important as releasing new features.
My idea is mainly to slowly move/enhance stuff from CGold 
(https://cgold.readthedocs.io/en/latest/) in the official documentation, so 
that people can rely on it. (By that I mean that people will more easily trust 
the documentation than CGold if they are new to CMake)

Lectem
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] cmake-gui on windows and qt5 dlls

[Lectem]

Right, as mentionned by Craig Scott, a script might do the trick ? Just a 
cmake-gui.bat that calls cmake-gui.exe should work.

De : Robert Maynard
Envoyé le :lundi 14 août 2017 15:24
À : Craig Scott
Cc : Clément Gregoire; CMake
Objet :Re: [CMake] cmake-gui on windows and qt5 dlls

More importantly symlinks are restricted to administrator accounts
only in Windows Vista/7/8. Windows 10 with Developer Mode activated
allows none-elevated accounts to create symlinks.

This is important as CMake does ship non-installer windows binaries.

On Mon, Aug 14, 2017 at 9:00 AM, Craig Scott  wrote:
>
>
> On Mon, Aug 14, 2017 at 9:05 PM, Clément Gregoire  wrote:
>>
>> Wouldn't it be possible to move it to a subfolder with the DLLs and put a
>> link next to cmake and ccmake? Executables look for DLLs in their directory
>> and it wouldn't pollute the PATH
>
>
> Symlinks are available on NTFS filesystems from Vista onwards. If the user
> installed CMake on, say, a FAT filesystem instead or on an old XP box (CMake
> appears to still try to support that), then symlinks wouldn't be available
> from what I can make out. One could potentially use a forwarding script of
> some kind though to achieve essentially the same thing.
>
>
>> I personally like to be able to launch it through the command line, it is
>> faster than looking for it and then browse for the folder.
>>
>>
>> Le lun. 14 août 2017 à 11:48, Craig Scott  a
>> écrit :
>>>
>>> This is a common problem, not just with CMake. I'm wondering if there's
>>> any real need for cmake-gui to be on the PATH at all, since it will usually
>>> be invoked by a desktop or menu icon. At the moment though, it is in the
>>> same directory as the cmake and ccmake executables which have a much
>>> stronger case for being on the PATH. There's a reasonable argument that
>>> cmake-gui should be in a different directory, then it wouldn't be an issue
>>> if shared Qt libs were used rather than static. I'll bring this up on the
>>> developer mailing list and see what discussions yield.
>>>
>>>
>>> On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher
>>>  wrote:

 Hi,

 I recently upgraded from cmake 3.3 to 3.9 on windows and got some
 problems during my build because it looks like the pre-compile binaries for
 windows are now shipping Qt5 - dlls instead static compile libs (since 3.5
 afaics).
 The problem is, that I had the path to cmake *before* the path to my own
 Qt5 libaries. So during the build / run of my application, the wrong
 libraries were loaded and I got a symbol lookup error.
 Would it be possible to use the static Qt5 libs instead or maybe prefix
 the Qt5 libs shipped with cmake-gui somehow?

 Thx,
 Christian

 --

 Powered by www.kitware.com

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

 Kitware offers various services to support the CMake community. For more
 information on each offering, please visit:

 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake
>>>
>>>
>>>
>>>
>>> --
>>> Craig Scott
>>> Melbourne, Australia
>>> https://crascit.com
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> 

Re: [CMake] Coverage support

[Lectem]

OK so I ended up doing the following :

Use a cmake script to detect coverage support and set up a new build type
+
Let CTest run GCov for me

Final result can be seen here : https://github.com/Lectem/cpp-boilerplate
link to the Coverage setup script : 
https://github.com/Lectem/cpp-boilerplate/blob/master/cmake/Coverage.cmake

This seems to be the best way to do it, it is non-intrusive (no 
CMAKE__FLAGS clobbering), plus it really does check that it is supported 
by the compiler, not assuming versions or anything.
If the user wants to build with coverage support, he only needs to use the 
Coverage build type, and can change the flags from the cache if needed, just as 
he would do with any build type.
Also not that since the codecov.io script runs GCov by default, using CTest is 
facultative. (but you need to make sure the gcov version matches the compiler 
used).


De : Konstantin Tokarev
Envoyé le :lundi 7 août 2017 19:52
À : Clément Gregoire; Rolf Eike Beer
Cc : Cmake Mailing List
Objet :Re: [CMake] Coverage support

 
 
07.08.2017, 20:50, "Clément Gregoire" <lec...@gmail.com>:
This is mainly why I started this thread, I want to know the best way to do 
this without using those variables.
CMAKE_lang_FLAGS is a pain as soon as someone wants to use add_subdirectory (be 
it to add an external project or your project being used in another) or a user 
wants to change the value. Those variables should really only be set by the 
toolchain file or from the command-line.

There's ExternalProject for this purpose
 
Other solutions were mentioned in my first mail, the easiest one being to add a 
new build type.
The other option is to uses something like a special script that will set those 
variables before your Cmakelists.txt (ie a toolchain file).

 
 
Le lun. 7 août 2017 à 17:22, Konstantin Tokarev <annu...@yandex.ru> a écrit :
 
07.08.2017, 17:24, "Clément Gregoire" <lec...@gmail.com>:
>> I usually stop reading Cmakelists.txt as soon as I see this
>>
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
>> -fprofile-arcs -ftest-coverage")
>>
>> The pthread thing there is likely wrong anyway, and the -Wall is entirely 
>> optional. The other things are needed, otherwise gcov will not produce any 
>> useful output.
>
> I don't have an issue with the flags per se, but with the usage of 
> set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern 
> cmake scripts.

How can one set global compiler flags without use of CMAKE_CXX_FLAGS or setting 
flags for each individual target?

>
>> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
>> target, which seems to be a difficult to scale on big projects
>>
>> No, you don't. It's entirely fine if you just run "make test" as I do in 
>> OSM2go.
> From what I saw in the documentation of the script :
>
>> # Param _testrunner The name of the target which runs the tests
>
> It seems to call directly the command named _testrunner, which is somehow 
> confirmed from the cmakelists :
>
>> # src/CMakelists.txt
>> add_executable(tests ${TEST_FILES})
>>
>> # Linking up all libraries
>>
>> target_link_libraries(tests complex)
>>
>> add_test(NAME example_test COMMAND tests)
>> # CMakelists.txt
>> setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage)
> From this I deduce that you need to call setup_target_for_coverage for each 
> different test executable.
>
> 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer <e...@sf-mail.de>:
>> Am 2017-08-07 11:06, schrieb Clément Gregoire:
>> I usually stop reading Cmakelists.txt as soon as I see this
>>
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
>> -fprofile-arcs -ftest-coverage")
>>
>> The pthread thing there is likely wrong anyway, and the -Wall is entirely 
>> optional. The other things are needed, otherwise gcov will not produce any 
>> useful output.
>>
>> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
>> target, which seems to be a difficult to scale on big projects
>>
>> No, you don't. It's entirely fine if you just run "make test" as I do in 
>> OSM2go.
>>
>> Eike
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Traini

Re: [CMake] CMake equivalent to Boost.Build site-config.jam oruser-config.jam

[Lectem]

I think that you are looking for the toolchain files :
https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html

The other option is to use a cmake script to specify your variables which 
includes CMakelists.txt (or the other way around if you can modify the 
CMakelists.txt). This would be quite similar to ctests scripts.
Some good examples are in Daniel Pfeifer’s « Effective cmake » talk 
https://github.com/boostcon/cppnow_presentations_2017/blob/master/05-19-2017_friday/effective_cmake__daniel_pfeifer__cppnow_05-19-2017.pdf


De : Brian Davis
Envoyé le :mardi 8 août 2017 20:09
À : cmake Mailing List
Objet :[CMake] CMake equivalent to Boost.Build site-config.jam oruser-config.jam


Is there a CMake equivalent to a site-config.jam or user-config.jam

http://www.boost.org/build/doc/html/bbv2/recipies/site-config.html
basically a CMake file the user can put in a project directory that CMake will 
read first when using cmake-gui that allows user to specify stuff they don't 
want to have to keep specifying in cmake-gui each "delete cache"
such as 
set( CMAKE_INSTALL_PREFIX ${CURRENT_LIST_DIR}/install CACHE STRING "" FORCE)
set( CMAKE_DEBUG_POSTFIX d CACHE STRING "" FORCE )

There is cmake.exe

-C  
but requires command line
come to think of it would be nice if 
set( CMAKE_GENERATOR_PLATFORM "Visual Studio 12 2013 Win64" )
in desired user config file and CMake would just "make it so" on clicking 
Generate.
I can do this with my own projects, by implementing it myself, but when 
checking out 3rd party projs they can be all over the map on config allowing a 
user-config.cmake would provide mechanism to tame the config problems.
Desired workflow
1) Checkout 3rd party proj
2) put a CMakeUser.txt or whatever file per project
3) Run CMake GUI Generate
4) Click Open Project
5) Change whatever manual bits in in gui
6) Update project suing git witch branches versions
7) Delete Cache
8) Return to 3
9) Doopy doopy doo whatever else



-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR

[lectem]

Hello guys,

So I downloaded the 3.9 release and thought my LTO nightmares were over but… 
cmake still isn’t using 
CMAKE__COMPILER_AR when linking on MSYS.

I’m using the « MSYS Makefiles » generator, and when building an executable it 
still uses the plain ar instead of gcc-ar…

CMAKE_CXX_COMPILER_AR is correctly set to C:/msys64/mingw64/bin/gcc-ar.exe but 
won’t use it…
I also tried to set CMAKE_AR to C:/msys64/mingw64/bin/gcc-ar.exe from cmake-gui 
but it’s not taken into account
Here’s the output :

[100%] Linking CXX executable BoilerPlate.exe
"/C/Program Files/CMake/bin/cmake.exe" -E remove -f 
CMakeFiles/BoilerPlate.dir/objects.a
/C/msys64/mingw64/bin/ar.exe cr CMakeFiles/BoilerPlate.dir/objects.a 
@CMakeFiles/BoilerPlate.dir/objects1.rsp
C:\msys64\mingw64\bin\ar.exe: CMakeFiles/BoilerPlate.dir/source/main.cpp.obj: 
plugin needed to handle lto object
/C/msys64/mingw64/bin/g++.exe -flto -fno-fat-lto-objects   -Wl,--whole-archive 
CMakeFiles/BoilerPlate.dir/objects.a -Wl,--no-whole-archive  -o BoilerPlate.exe 
-Wl,--out-implib,libBoilerPlate.dll.a 
-Wl,--major-image-version,0,--minor-image-version,0 
@CMakeFiles/BoilerPlate.dir/linklibs.rsp

I’m not sure if it is a Windows/MSYS related problem (I think it is), but I 
really don’t understand why CMAKE wants to use C:/msys64/mingw64/bin/ar.exe so 
much and not the one in CMAKE_AR / CMAKE_CXX_COMPILER_AR…

If you guys have any idea.

Thanks,
Lectem
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] DLL handling under CMake

[lectem]

I managed to get it working by using an intermediate script.
One might want to generate the script instead of using the « RUN_IT » variable 
trick.
This was only tested on Windows, but seems to work fine.
Put the following code in a xx.cmake file, include it from your 
CMakeLists.txt and enjoy.


# This is a helper script to run BundleUtilities fixup_bundle as postbuild
# for a target. The primary use case is to copy .DLLs to the build directory for
# the Windows platform. It allows generator expressions to be used to determine
# the binary location
#
# Usage : run_fixup(TARGET LIBS DIRS)
# - TARGET : A cmake target
# - See fixup_bundle for LIBS and DIRS arguments

if(RUN_IT)
# Script ran by the add_custom_command
include(BundleUtilities)
fixup_bundle("${TO_FIXUP_FILE}" "${TO_FIXUP_LIBS}" "${TO_FIXUP_DIRS}")
# End of script ran by the add_custom_command
else()

set(THIS_FILE ${CMAKE_CURRENT_LIST_FILE})
message(${THIS_FILE})
function(run_fixup _target _libs _dirs)
message(${THIS_FILE})
add_custom_command(
TARGET ${_target} POST_BUILD
COMMAND ${CMAKE_COMMAND} -DRUN_IT:BOOL=ON 
-DTO_FIXUP_FILE=$ -DTO_FIXUP_LIBS=${_libs} 
-DTO_FIXUP_DIRS=${_dirs}  -P ${THIS_FILE}
COMMENT "Fixing up dependencies for ${_target}"
VERBATIM
)

endfunction()

endif()


De : Clément Gregoire
Envoyé le :jeudi 4 mai 2017 08:37
À : Hendrik Sattler; Louis-Paul CORDIER; Cmake Mailing List
Objet :Re: [CMake] DLL handling under CMake

I'd also be interested in this. I saw an old mail in the ML about this, but it 
seems fixup_bundle is old and cant use generator expressions, making it hard to 
use (I don't want to hardcode the executable path).

Do you have a sample for this ?
CMake would really benefit from having those features made more accessible 
instead of everyone having to write its own script 
Le sam. 29 avr. 2017 22:10, Hendrik Sattler  a écrit :


Am 27. April 2017 10:43:50 MESZ schrieb Louis-Paul CORDIER 
:
>This steps are tedious and I'm wondering if there is a mechanism that
>exists or that have to be imagined to make the DLL nightmare end.

I use BundleUtilities to achieve the copying of DLL files to the installation 
directory. The main problem for this is to enumerate the needed directories.

I use the same for copying DLL files to the output directory to ease debugging.

The advantage is the inspection of the exe for really needed DLL files. This 
AUTOMATICALLY handles the case debug vs. release.

HS

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake