Re: [CMake] Appending to CMAKE_CXX_FLAGS

2018-09-11 Thread Eric Noulard
Le mar. 11 sept. 2018 à 22:09, Michael Jackson a écrit : > I add it manually each and every time. I have to tell all new developers > to remember to add the flag otherwise they are still sitting after an hour > waiting on our code to compile wondering why it takes so long. Then it hits > us, "Oh,

[CMake] SOVERSION and Mac library id in shared library made from assembly files

2018-09-11 Thread René J . V . Bertin
Hi, I have a little project that creates a shared library from a pair of assembly files. I've been trying to follow examples such that the generated library - has versioning (libFastCompression.1.dylib on Mac or libFastCompression.so.1 on Linux) - has the full path as its ID on Mac I get this

Re: [CMake] Appending to CMAKE_CXX_FLAGS

2018-09-11 Thread Thompson, KT
Michael, I agree heartily with your frustration concerning how CMake handles compiler flags -- especially when the FLAG strings seen in cmake-gui don't match the baseline flags used by the build. I use a heavy handed, old-fashioned approach to solve this problem. I ignore all of CMake's defau

Re: [CMake] Appending to CMAKE_CXX_FLAGS

2018-09-11 Thread Michael Jackson
I add it manually each and every time. I have to tell all new developers to remember to add the flag otherwise they are still sitting after an hour waiting on our code to compile wondering why it takes so long. Then it hits us, "Oh, Yeah. Open CMake-Gui and set the /MP flag". I'm frustrated at t

Re: [CMake] Appending to CMAKE_CXX_FLAGS

2018-09-11 Thread Michael Jackson
Just to be clear I _only_ need it when the generator is Visual Studio so I did the following: if(MSVC_IDE)   add_compile_options(/MP) endif() >From a clean build directory that did not add it to the CMAKE_CXX_FLAGS when >viewed in CMake-Gui. -- Mike Jackson From: Marc CHEVRIER

Re: [CMake] Appending to CMAKE_CXX_FLAGS

2018-09-11 Thread Richard A. Smith
On 09/11/2018 01:03 PM, Marc CHEVRIER wrote: The best approach is to use properties (see https://cmake.org/cmake/help/git-master/manual/cmake-properties.7.html). At directory level and target level you can use property 'COMPILE_OPTIONS'.  These properties can be updated using, respectively '

Re: [CMake] Appending to CMAKE_CXX_FLAGS

2018-09-11 Thread Innokentiy Alaytsev
Hello! Did you consider adding the flag manually during project configuration? I do not know you use case, but after some thinking about the best way of achieving multiprocess compilation under MSVS with CMake I decided, that the simplest, most portable and flexible is to just add this flag manual

Re: [CMake] Appending to CMAKE_CXX_FLAGS

2018-09-11 Thread Marc CHEVRIER
If you set directory property at the top level CMakeList.txt, before any target definition, all targets will inherit this value. And, because property 'COMPILE_OPTIONS' supports generator expressions (see https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html), you can specif

Re: [CMake] Appending to CMAKE_CXX_FLAGS

2018-09-11 Thread Michael Jackson
Hmm. The idea for the “/MP” flags for those that don’t use Visual Studio is that it will inform the compiler to use all the cores on the system to compile. Much like Ninja does automatically and “make -jN” does for makefiles. Essentially I want to automatically add the “/MP” flag anytime that I

Re: [CMake] Appending to CMAKE_CXX_FLAGS

2018-09-11 Thread Marc CHEVRIER
The best approach is to use properties (see https://cmake.org/cmake/help/git-master/manual/cmake-properties.7.html). At directory level and target level you can use property 'COMPILE_OPTIONS'. These properties can be updated using, respectively 'add_compile_options' and 'target_compile_options'.

[CMake] Appending to CMAKE_CXX_FLAGS

2018-09-11 Thread Michael Jackson
What is the “modern” way to append to CMAKE_CXX_FLAGS? This is the logic that I would like: If (MSVC)     Set(CMAKE_CXX_FLAGS ${ CMAKE_CXX_FLAGS} “/MP”) Endif() I have always heard that appending to the compile flags in this way is “bad”. What is the best practice for doing

Re: [CMake] Problems with static jpeg library

2018-09-11 Thread Eric Noulard
Le mar. 11 sept. 2018 à 16:10, a écrit : > Hi, > > thank you for your reply. I could solve the problem. The part I didn't > knew was that static libraries also needed to be compiled with -fPIC. > I've found a good summary of this topic at > https://lists.debian.org/debian-devel/2016/05/msg00309.h

Re: [CMake] Problems with static jpeg library

2018-09-11 Thread world
Hi, thank you for your reply. I could solve the problem. The part I didn't knew was that static libraries also needed to be compiled with -fPIC. I've found a good summary of this topic at https://lists.debian.org/debian-devel/2016/05/msg00309.html I want to share it for those, who also stumbl

Re: [CMake] Joining an OBJECT and a SHARED library

2018-09-11 Thread Robert Maynard
I believe what you are looking for in the CMake 3.12 improvements to object libraries. In 3.12 the target_link_libraries command now supports linking to an object library to embed the object files ( only on direct dependencies, no propagation of .objs ) and also propagates usage requirements like

Re: [CMake] Problems with static jpeg library

2018-09-11 Thread Rolf Eike Beer
wo...@masterdevops.eu wrote: > Hi, > > I am trying to compile the project libgd > (https://github.com/libgd/libgd) with the option ENABLE_JPEG enabled. > > I.e. first I downloaded the source code of libjpeg-turbo from > https://sourceforge.net/projects/libjpeg-turbo/files/2.0.0/, compiled it You

[CMake] Problems with static jpeg library

2018-09-11 Thread world
Hi, I am trying to compile the project libgd (https://github.com/libgd/libgd) with the option ENABLE_JPEG enabled. I.e. first I downloaded the source code of libjpeg-turbo from https://sourceforge.net/projects/libjpeg-turbo/files/2.0.0/, compiled it and afterwards I started to compile libgd