setting/removing compiler flag (-g) for a single project directory

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

setting/removing compiler flag (-g) for a single project directory

René J. V.  Bertin
Hi,

Is it possible to  set and/or remove compiler arguments on a project subdirectory that holds a tree with sources of a considerable number of build targets?

An example to make this more concrete: I have a project that contains

common_libs
plugins/foo
plugins/this_one

I'm just interested in building plugins/this_one and can do so by calling make && make install/fast inside the build/plugins/this_one directory. All plugin dependencies are already installed (with debug info). The build/common_libs directory gets pretty big and is expensive to build, so ideally I would build everything in there with different flags, basically replacing -O3|-O2 with -Os and removing the -g option, possibly even running a strip before continuing the rest of the build.

I know one can do this kind of thing per target or even per file, but how does one do it on a directory basis? Do I have to cache the original CMAKE_C*_FLAGS value before modifying it in common_libs/CMakeLists.txt , and restore it before returning from that file? Or is there a more elegant method?

Thanks,
René
--

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
Reply | Threaded
Open this post in threaded view
|

Re: setting/removing compiler flag (-g) for a single project directory

René J. V.  Bertin
On Friday September 15 2017 16:51:24 Steven Velez wrote:

>Yeah... I didn't mean to respond personally... i didn't realize my client
>was doing that and not the list.

OK, replying back to the list then.

>What do you mean by "variables related to targets have global scope"?

I probably could have been a bit less vague. Defining a target in a subdirectory sets something that behaves like a global variable (pardon, constant :)), at least for libraries. That's the whole point of that common_dir subtree: it defines library targets which are then used for linking the plugin.

R.

>
>On Fri, Sep 15, 2017 at 3:44 PM, René J.V. Bertin <[hidden email]>
>wrote:
>
>> On Friday September 15 2017 15:34:34 Steven Velez wrote:
>>
>> Logically that's what I'd expect, but then the variables related to
>> targets have global scope, variables set in a module directories too etc. I
>> preferred to ask, so thanks :)
>>
>> R.
>>
>> >All directories in cmake have their own scopes which are initialized by
>> the
>> >scope of the parent directory.
>> >
>> >So, if you set the variables you wish to set in CMakeLists.txt of
>> >common_libs, they should not influence the builds in the plugin directory,
>> >but will influence the builds in that directory and subdirectories.
>> >
>> >https://cmake.org/cmake/help/v3.9/manual/cmake-language.7.
>> html#cmake-language-variables
>> >
>> >For more info.
>> >
>> >Steven

--

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
Reply | Threaded
Open this post in threaded view
|

Re: setting/removing compiler flag (-g) for a single project directory

Steven Velez
Gotcha...  yeah target definitions are available globally, in all directories after they are defined (source order is important).  I had never thought of this as a global variable or constant, but I guess in a way it is.
In that way, then I would think it is a sort of special case...  but I suppose the experts should chime in.

Steven

On Sat, Sep 16, 2017 at 4:07 AM, René J.V. Bertin <[hidden email]> wrote:
On Friday September 15 2017 16:51:24 Steven Velez wrote:

>Yeah... I didn't mean to respond personally... i didn't realize my client
>was doing that and not the list.

OK, replying back to the list then.

>What do you mean by "variables related to targets have global scope"?

I probably could have been a bit less vague. Defining a target in a subdirectory sets something that behaves like a global variable (pardon, constant :)), at least for libraries. That's the whole point of that common_dir subtree: it defines library targets which are then used for linking the plugin.

R.

>
>On Fri, Sep 15, 2017 at 3:44 PM, René J.V. Bertin <[hidden email]>
>wrote:
>
>> On Friday September 15 2017 15:34:34 Steven Velez wrote:
>>
>> Logically that's what I'd expect, but then the variables related to
>> targets have global scope, variables set in a module directories too etc. I
>> preferred to ask, so thanks :)
>>
>> R.
>>
>> >All directories in cmake have their own scopes which are initialized by
>> the
>> >scope of the parent directory.
>> >
>> >So, if you set the variables you wish to set in CMakeLists.txt of
>> >common_libs, they should not influence the builds in the plugin directory,
>> >but will influence the builds in that directory and subdirectories.
>> >
>> >https://cmake.org/cmake/help/v3.9/manual/cmake-language.7.
>> html#cmake-language-variables
>> >
>> >For more info.
>> >
>> >Steven

--

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