[CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly
Hi, all,
I try to use some gcc link option and libs(except libs link by
target_link_libraries(...)), i researched and try to use
'CMAKE_EXE_LINKER_FLAGS' in a simple project, as below:
in dir, there are 5 files:
-hello.h
-hello.c
-main.c
-hello.o
-libhello.a
hello.o was compiled by hello.c(gcc -c hello.c) and libhello.a contained
hello.o. And other 3 files content:
1.In hello.h:
void hello();
2.In hello.c:
#include
void hello()
{
printf("hello\n");
}
3.In main.c:
#include "hello.h"
void main()
{
hello();
}
When i used gcc -o main main.c libhello.a, the exe file: main generated, and
it work well.
Then i write a CMakeLists.txt, the content as below:
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello")
add_executable(main main.c)
When i cmake&make this project, an error occurred: main.c:undefined
reference to 'hello'.
Since i wil add a complicated link option and would not conflict with libs
link by target_link_libraries(...), i should figure out how to use
'CMAKE_EXE_LINKER_FLAGS' or other ways, could you please give me some
advices? :-)
Thanks,
Chao
--
View this message in context:
http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495.html
Sent from the CMake mailing list archive at Nabble.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
[CMake] Setting a value in a sub-project
CMake (version 3.5.2) surprised me with how it's passing values to
sub-projects, so I was wondering if this is expected behavior. Here's an
example of what I mean. Let's say I have a project Foo in a directory of
the same name. It contains a third-party library called Bar which has a
CMakeLists.txt file that looks like:
cmake_minimum_required(VERSION 2.8.12)
option(OPT1
"Set to OFF|ON (default is OFF) to control build of Bar library" OFF)
if(OPT1)
message("Bar: OPT1 is on")
else(OPT1)
message("Bar: OPT1 is off")
endif(OPT1)
I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes Bar:
cmake_minimum_required(VERSION 2.8.12)
set(OPT1 ON FORCE)
if(OPT1)
message("Foo: OPT1 is on")
else(OPT1)
message("Foo: OPT1 is off")
endif(OPT1)
add_subdirectory(Bar)
The first time I run cmake the message output is:
Foo: OPT1 is on
Bar: OPT1 is off
If I run cmake again, I get:
Foo: OPT1 is on
Bar: OPT1 is on
If this is expected behavior, is there any way I can ensure Bar receives
the value of OPT1 the first time? It makes a huge difference when the
option controls, for example, whether a static or dynamic library will be
built.
Thanks,
Doug
--
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] Setting a value in a sub-project
Hi Doug,
your syntax for `set()` in Foo is incorrect; you're actually setting a
non-cache variable OPT1 do the value "ON;FORCE".
You want to set the *cache* variable OPT1, which would be done like this:
set(OPT1 ON CACHE BOOL "Set to OFF|ON (default is OFF) to control build
of Bar library" FORCE)
Petr
On 20 May 2016 at 11:24, Doug Cuthbertson
wrote:
>
> CMake (version 3.5.2) surprised me with how it's passing values to
> sub-projects, so I was wondering if this is expected behavior. Here's an
> example of what I mean. Let's say I have a project Foo in a directory of
> the same name. It contains a third-party library called Bar which has a
> CMakeLists.txt file that looks like:
>
> cmake_minimum_required(VERSION 2.8.12)
>
> option(OPT1
> "Set to OFF|ON (default is OFF) to control build of Bar library" OFF)
>
> if(OPT1)
> message("Bar: OPT1 is on")
> else(OPT1)
> message("Bar: OPT1 is off")
> endif(OPT1)
>
> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes Bar:
>
> cmake_minimum_required(VERSION 2.8.12)
>
> set(OPT1 ON FORCE)
> if(OPT1)
> message("Foo: OPT1 is on")
> else(OPT1)
> message("Foo: OPT1 is off")
> endif(OPT1)
> add_subdirectory(Bar)
>
> The first time I run cmake the message output is:
>
> Foo: OPT1 is on
> Bar: OPT1 is off
>
> If I run cmake again, I get:
>
> Foo: OPT1 is on
> Bar: OPT1 is on
>
> If this is expected behavior, is there any way I can ensure Bar receives
> the value of OPT1 the first time? It makes a huge difference when the
> option controls, for example, whether a static or dynamic library will be
> built.
>
> Thanks,
> Doug
>
> --
>
> 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
Re: [CMake] Setting a value in a sub-project
Hi Petr,
Thank you so much. I'll try it when I get in to work this morning.
Doug
On Fri, May 20, 2016 at 5:37 AM, Petr Kmoch wrote:
> Hi Doug,
>
> your syntax for `set()` in Foo is incorrect; you're actually setting a
> non-cache variable OPT1 do the value "ON;FORCE".
>
> You want to set the *cache* variable OPT1, which would be done like this:
>
> set(OPT1 ON CACHE BOOL "Set to OFF|ON (default is OFF) to control build
> of Bar library" FORCE)
>
> Petr
>
> On 20 May 2016 at 11:24, Doug Cuthbertson
> wrote:
>
>>
>> CMake (version 3.5.2) surprised me with how it's passing values to
>> sub-projects, so I was wondering if this is expected behavior. Here's an
>> example of what I mean. Let's say I have a project Foo in a directory of
>> the same name. It contains a third-party library called Bar which has a
>> CMakeLists.txt file that looks like:
>>
>> cmake_minimum_required(VERSION 2.8.12)
>>
>> option(OPT1
>> "Set to OFF|ON (default is OFF) to control build of Bar library"
>> OFF)
>>
>> if(OPT1)
>> message("Bar: OPT1 is on")
>> else(OPT1)
>> message("Bar: OPT1 is off")
>> endif(OPT1)
>>
>> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes
>> Bar:
>>
>> cmake_minimum_required(VERSION 2.8.12)
>>
>> set(OPT1 ON FORCE)
>> if(OPT1)
>> message("Foo: OPT1 is on")
>> else(OPT1)
>> message("Foo: OPT1 is off")
>> endif(OPT1)
>> add_subdirectory(Bar)
>>
>> The first time I run cmake the message output is:
>>
>> Foo: OPT1 is on
>> Bar: OPT1 is off
>>
>> If I run cmake again, I get:
>>
>> Foo: OPT1 is on
>> Bar: OPT1 is on
>>
>> If this is expected behavior, is there any way I can ensure Bar receives
>> the value of OPT1 the first time? It makes a huge difference when the
>> option controls, for example, whether a static or dynamic library will be
>> built.
>>
>> Thanks,
>> Doug
>>
>> --
>>
>> 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
Re: [CMake] Setting a value in a sub-project
You don't have to create a cache variable for this. Put yourself in the
position of CMake;
* While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1 ON
FORCE) command, which tells CMake to create a *variable* called OPT1 with
value ON
* Then CMake is asked to include Bar
* While scanning Bar, CMake encounters the option() command, so it will
create an option called OPT1
* end then nothing, CMake finished scanning
Only the second time around, when CMake encounters the set(OPT1..) command,
it will have gained knowledge of the presence of the OPT1 option, and hence
it will realize it needs to change that option instead of creating a
variable with that name.
So to me, your output is exactly as expected. I suspect if you include Bar
before setting the option, you will get the behaviour you expected. This,
to me, makes perfect sense, as Bar is a dependency of Foo, and hence needs
to be setup before you start setting up Foo. You wouldn't compile Foo
before compiling Bar, so why would that be different for the configuration
step.
Sincerely,
Jakob
On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson <
doug.cuthbert...@gmail.com> wrote:
>
> CMake (version 3.5.2) surprised me with how it's passing values to
> sub-projects, so I was wondering if this is expected behavior. Here's an
> example of what I mean. Let's say I have a project Foo in a directory of
> the same name. It contains a third-party library called Bar which has a
> CMakeLists.txt file that looks like:
>
> cmake_minimum_required(VERSION 2.8.12)
>
> option(OPT1
> "Set to OFF|ON (default is OFF) to control build of Bar library" OFF)
>
> if(OPT1)
> message("Bar: OPT1 is on")
> else(OPT1)
> message("Bar: OPT1 is off")
> endif(OPT1)
>
> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes Bar:
>
> cmake_minimum_required(VERSION 2.8.12)
>
> set(OPT1 ON FORCE)
> if(OPT1)
> message("Foo: OPT1 is on")
> else(OPT1)
> message("Foo: OPT1 is off")
> endif(OPT1)
> add_subdirectory(Bar)
>
> The first time I run cmake the message output is:
>
> Foo: OPT1 is on
> Bar: OPT1 is off
>
> If I run cmake again, I get:
>
> Foo: OPT1 is on
> Bar: OPT1 is on
>
> If this is expected behavior, is there any way I can ensure Bar receives
> the value of OPT1 the first time? It makes a huge difference when the
> option controls, for example, whether a static or dynamic library will be
> built.
>
> Thanks,
> Doug
>
> --
>
> 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
Re: [CMake] Setting a value in a sub-project
The situation already involves a cache variable, though: `option(abc "cmt"
ON)` is just syntactic sugar for `set(abc ON CACHE BOOL "cmt")`.
Petr
On 20 May 2016 at 13:03, Jakob van Bethlehem
wrote:
> You don't have to create a cache variable for this. Put yourself in the
> position of CMake;
> * While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1
> ON FORCE) command, which tells CMake to create a *variable* called OPT1
> with value ON
> * Then CMake is asked to include Bar
> * While scanning Bar, CMake encounters the option() command, so it will
> create an option called OPT1
> * end then nothing, CMake finished scanning
>
> Only the second time around, when CMake encounters the set(OPT1..)
> command, it will have gained knowledge of the presence of the OPT1 option,
> and hence it will realize it needs to change that option instead of
> creating a variable with that name.
>
> So to me, your output is exactly as expected. I suspect if you include Bar
> before setting the option, you will get the behaviour you expected. This,
> to me, makes perfect sense, as Bar is a dependency of Foo, and hence needs
> to be setup before you start setting up Foo. You wouldn't compile Foo
> before compiling Bar, so why would that be different for the configuration
> step.
>
> Sincerely,
> Jakob
>
> On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson <
> doug.cuthbert...@gmail.com> wrote:
>
>>
>> CMake (version 3.5.2) surprised me with how it's passing values to
>> sub-projects, so I was wondering if this is expected behavior. Here's an
>> example of what I mean. Let's say I have a project Foo in a directory of
>> the same name. It contains a third-party library called Bar which has a
>> CMakeLists.txt file that looks like:
>>
>> cmake_minimum_required(VERSION 2.8.12)
>>
>> option(OPT1
>> "Set to OFF|ON (default is OFF) to control build of Bar library"
>> OFF)
>>
>> if(OPT1)
>> message("Bar: OPT1 is on")
>> else(OPT1)
>> message("Bar: OPT1 is off")
>> endif(OPT1)
>>
>> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes
>> Bar:
>>
>> cmake_minimum_required(VERSION 2.8.12)
>>
>> set(OPT1 ON FORCE)
>> if(OPT1)
>> message("Foo: OPT1 is on")
>> else(OPT1)
>> message("Foo: OPT1 is off")
>> endif(OPT1)
>> add_subdirectory(Bar)
>>
>> The first time I run cmake the message output is:
>>
>> Foo: OPT1 is on
>> Bar: OPT1 is off
>>
>> If I run cmake again, I get:
>>
>> Foo: OPT1 is on
>> Bar: OPT1 is on
>>
>> If this is expected behavior, is there any way I can ensure Bar receives
>> the value of OPT1 the first time? It makes a huge difference when the
>> option controls, for example, whether a static or dynamic library will be
>> built.
>>
>> Thanks,
>> Doug
>>
>> --
>>
>> 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
>
--
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] Setting a value in a sub-project
Ah, nice. Good to know. But then still that cache variable is not created
until *after* it was set by Foo, because it is only created when adding the
Bar subdirectory, which explains the output.
Sincerely,
Jakob
On Fri, May 20, 2016 at 1:18 PM, Petr Kmoch wrote:
> The situation already involves a cache variable, though: `option(abc "cmt"
> ON)` is just syntactic sugar for `set(abc ON CACHE BOOL "cmt")`.
>
> Petr
>
>
> On 20 May 2016 at 13:03, Jakob van Bethlehem
> wrote:
>
>> You don't have to create a cache variable for this. Put yourself in the
>> position of CMake;
>> * While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1
>> ON FORCE) command, which tells CMake to create a *variable* called OPT1
>> with value ON
>> * Then CMake is asked to include Bar
>> * While scanning Bar, CMake encounters the option() command, so it will
>> create an option called OPT1
>> * end then nothing, CMake finished scanning
>>
>> Only the second time around, when CMake encounters the set(OPT1..)
>> command, it will have gained knowledge of the presence of the OPT1 option,
>> and hence it will realize it needs to change that option instead of
>> creating a variable with that name.
>>
>> So to me, your output is exactly as expected. I suspect if you include
>> Bar before setting the option, you will get the behaviour you expected.
>> This, to me, makes perfect sense, as Bar is a dependency of Foo, and hence
>> needs to be setup before you start setting up Foo. You wouldn't compile Foo
>> before compiling Bar, so why would that be different for the configuration
>> step.
>>
>> Sincerely,
>> Jakob
>>
>> On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson <
>> doug.cuthbert...@gmail.com> wrote:
>>
>>>
>>> CMake (version 3.5.2) surprised me with how it's passing values to
>>> sub-projects, so I was wondering if this is expected behavior. Here's an
>>> example of what I mean. Let's say I have a project Foo in a directory of
>>> the same name. It contains a third-party library called Bar which has a
>>> CMakeLists.txt file that looks like:
>>>
>>> cmake_minimum_required(VERSION 2.8.12)
>>>
>>> option(OPT1
>>> "Set to OFF|ON (default is OFF) to control build of Bar library"
>>> OFF)
>>>
>>> if(OPT1)
>>> message("Bar: OPT1 is on")
>>> else(OPT1)
>>> message("Bar: OPT1 is off")
>>> endif(OPT1)
>>>
>>> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes
>>> Bar:
>>>
>>> cmake_minimum_required(VERSION 2.8.12)
>>>
>>> set(OPT1 ON FORCE)
>>> if(OPT1)
>>> message("Foo: OPT1 is on")
>>> else(OPT1)
>>> message("Foo: OPT1 is off")
>>> endif(OPT1)
>>> add_subdirectory(Bar)
>>>
>>> The first time I run cmake the message output is:
>>>
>>> Foo: OPT1 is on
>>> Bar: OPT1 is off
>>>
>>> If I run cmake again, I get:
>>>
>>> Foo: OPT1 is on
>>> Bar: OPT1 is on
>>>
>>> If this is expected behavior, is there any way I can ensure Bar receives
>>> the value of OPT1 the first time? It makes a huge difference when the
>>> option controls, for example, whether a static or dynamic library will be
>>> built.
>>>
>>> Thanks,
>>> Doug
>>>
>>> --
>>>
>>> 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
>>
>
>
--
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
Re: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly
Is there a reason to not use target_link_libraries here? For the purposes
of your example there's no reason to be using CMAKE_EXE_LINKER_FLAGS. What
are you actually trying to accomplish? Because there is almost certainly a
better way to achieve your desired result than via CMAKE_EXE_LINKER_FLAGS.
- Chuck
On Fri, May 20, 2016 at 4:28 AM, Chaos Zhang wrote:
> Hi, all,
>
> I try to use some gcc link option and libs(except libs link by
> target_link_libraries(...)), i researched and try to use
> 'CMAKE_EXE_LINKER_FLAGS' in a simple project, as below:
> in dir, there are 5 files:
>
> -hello.h
> -hello.c
> -main.c
> -hello.o
> -libhello.a
>
> hello.o was compiled by hello.c(gcc -c hello.c) and libhello.a contained
> hello.o. And other 3 files content:
> 1.In hello.h:
>
> void hello();
>
> 2.In hello.c:
>
> #include
> void hello()
> {
> printf("hello\n");
> }
>
> 3.In main.c:
>
> #include "hello.h"
> void main()
> {
>hello();
> }
>
> When i used gcc -o main main.c libhello.a, the exe file: main generated,
> and
> it work well.
> Then i write a CMakeLists.txt, the content as below:
>
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello")
> add_executable(main main.c)
>
> When i cmake&make this project, an error occurred: main.c:undefined
> reference to 'hello'.
>
> Since i wil add a complicated link option and would not conflict with libs
> link by target_link_libraries(...), i should figure out how to use
> 'CMAKE_EXE_LINKER_FLAGS' or other ways, could you please give me some
> advices? :-)
>
> Thanks,
> Chao
>
>
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495.html
> Sent from the CMake mailing list archive at Nabble.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
>
--
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] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly
Nice to see you again, Mr. Atkins. I was trying to add a very long gcc link
option to a ELF file, there are some options, like -whole-archive，
-rpath，and i don't known how to set in CMake, so i decided to use original
gcc option, is there better way to solve this?
Chuck Atkins wrote
> Is there a reason to not use target_link_libraries here? For the purposes
> of your example there's no reason to be using CMAKE_EXE_LINKER_FLAGS.
> What
> are you actually trying to accomplish? Because there is almost certainly a
> better way to achieve your desired result than via CMAKE_EXE_LINKER_FLAGS.
>
> - Chuck
>
> On Fri, May 20, 2016 at 4:28 AM, Chaos Zhang <
> zcsd2012@
> > wrote:
>
>> Hi, all,
>>
>> I try to use some gcc link option and libs(except libs link by
>> target_link_libraries(...)), i researched and try to use
>> 'CMAKE_EXE_LINKER_FLAGS' in a simple project, as below:
>> in dir, there are 5 files:
>>
>> -hello.h
>> -hello.c
>> -main.c
>> -hello.o
>> -libhello.a
>>
>> hello.o was compiled by hello.c(gcc -c hello.c) and libhello.a contained
>> hello.o. And other 3 files content:
>> 1.In hello.h:
>>
>> void hello();
>>
>> 2.In hello.c:
>>
>> #include
>
>> void hello()
>> {
>> printf("hello\n");
>> }
>>
>> 3.In main.c:
>>
>> #include "hello.h"
>> void main()
>> {
>>hello();
>> }
>>
>> When i used gcc -o main main.c libhello.a, the exe file: main generated,
>> and
>> it work well.
>> Then i write a CMakeLists.txt, the content as below:
>>
>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello")
>> add_executable(main main.c)
>>
>> When i cmake&make this project, an error occurred: main.c:undefined
>> reference to 'hello'.
>>
>> Since i wil add a complicated link option and would not conflict with
>> libs
>> link by target_link_libraries(...), i should figure out how to use
>> 'CMAKE_EXE_LINKER_FLAGS' or other ways, could you please give me some
>> advices? :-)
>>
>> Thanks,
>> Chao
>>
>>
>>
>> --
>> View this message in context:
>> http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495.html
>> Sent from the CMake mailing list archive at Nabble.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
>>
>
> --
>
> 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
--
View this message in context:
http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495p7593503.html
Sent from the CMake mailing list archive at Nabble.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
Re: [CMake] Setting a value in a sub-project
Petr - using:
set(OPT1 ON CACHE BOOL "Set to OFF|ON (default is OFF) to control build
of Bar library" FORCE)
works like a champ!
Jakob - Thanks for the suggestion, but I can't put "add_subdirectory(Bar)"
before setting the variable(s) in Foo's CMakeLists.txt, because cmake
finishes configuring everything under Bar before it reads the set commands
in Foo.
Thanks again for all your help.
Doug
On Fri, May 20, 2016 at 8:14 AM, Jakob van Bethlehem <
jsvanbethle...@gmail.com> wrote:
> Ah, nice. Good to know. But then still that cache variable is not created
> until *after* it was set by Foo, because it is only created when adding the
> Bar subdirectory, which explains the output.
>
> Sincerely,
> Jakob
>
>
> On Fri, May 20, 2016 at 1:18 PM, Petr Kmoch wrote:
>
>> The situation already involves a cache variable, though: `option(abc
>> "cmt" ON)` is just syntactic sugar for `set(abc ON CACHE BOOL "cmt")`.
>>
>> Petr
>>
>>
>> On 20 May 2016 at 13:03, Jakob van Bethlehem
>> wrote:
>>
>>> You don't have to create a cache variable for this. Put yourself in the
>>> position of CMake;
>>> * While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1
>>> ON FORCE) command, which tells CMake to create a *variable* called OPT1
>>> with value ON
>>> * Then CMake is asked to include Bar
>>> * While scanning Bar, CMake encounters the option() command, so it will
>>> create an option called OPT1
>>> * end then nothing, CMake finished scanning
>>>
>>> Only the second time around, when CMake encounters the set(OPT1..)
>>> command, it will have gained knowledge of the presence of the OPT1 option,
>>> and hence it will realize it needs to change that option instead of
>>> creating a variable with that name.
>>>
>>> So to me, your output is exactly as expected. I suspect if you include
>>> Bar before setting the option, you will get the behaviour you expected.
>>> This, to me, makes perfect sense, as Bar is a dependency of Foo, and hence
>>> needs to be setup before you start setting up Foo. You wouldn't compile Foo
>>> before compiling Bar, so why would that be different for the configuration
>>> step.
>>>
>>> Sincerely,
>>> Jakob
>>>
>>> On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson <
>>> doug.cuthbert...@gmail.com> wrote:
>>>
CMake (version 3.5.2) surprised me with how it's passing values to
sub-projects, so I was wondering if this is expected behavior. Here's an
example of what I mean. Let's say I have a project Foo in a directory of
the same name. It contains a third-party library called Bar which has a
CMakeLists.txt file that looks like:
cmake_minimum_required(VERSION 2.8.12)
option(OPT1
"Set to OFF|ON (default is OFF) to control build of Bar library"
OFF)
if(OPT1)
message("Bar: OPT1 is on")
else(OPT1)
message("Bar: OPT1 is off")
endif(OPT1)
I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes
Bar:
cmake_minimum_required(VERSION 2.8.12)
set(OPT1 ON FORCE)
if(OPT1)
message("Foo: OPT1 is on")
else(OPT1)
message("Foo: OPT1 is off")
endif(OPT1)
add_subdirectory(Bar)
The first time I run cmake the message output is:
Foo: OPT1 is on
Bar: OPT1 is off
If I run cmake again, I get:
Foo: OPT1 is on
Bar: OPT1 is on
If this is expected behavior, is there any way I can ensure Bar
receives the value of OPT1 the first time? It makes a huge difference when
the option controls, for example, whether a static or dynamic library will
be built.
Thanks,
Doug
--
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
Re: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly
> -rpath
RPATHs are automatically added by CMake to executables so they can use
libraries from the build tree.
> -whole-archive
>
whole-archive is definitely trickier since you shouldn't be applying it to
the entire executable but instead wrapping individual libraries with it.
Conveniently, you can pass link options directly with
target_link_libraries. So you could have:
# Just an example, find_library calls should really be isolated to separate
find modules
find_library(FOO_LIBRARY foo)
set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY} -Wl,--no-whole-archive")
add_executable(hello main.c)
target_link_libraries(hello ${FOO_LIBRARY})
>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello")
>
CMAKE_EXE_LINKER_FLAGS should work for other more general cases that aren't
tied to specific libraries. The problem with your example is likely not
using an absolute path for -L since the compilation is actually taking
place in a nested work directory somewhere.
--
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] Argh! Thwarted at every turn!
I'm using CMake 3.5.2 generating for Linux / OSX / Visual Studio. I'm creating a shared library. This shared library is constructed mostly from other libraries (which are also built in other directories by this cmake setup). I have been doing this for a long time and it worked fine: add_library(mylibrary SHARED foo.cpp foo.h bar.cpp bar.h ...) target_link_libraries(mylibrary PRIVATE mylib1 mylib2 VerData ...) Fine. Now the problem is that I need to generate a link map and I have a script that parses the object files in mylibrary to create the link map (the link map is only created/used on Linux of course). Well, I can't find any way to get a listing of the .o files that are generated by compiling the .cpp files in the add_library() call above. So, instead I decided to turn those files into a library, themselves, then I can use $ with my add_custom_command() that runs the link map generator script. However, then I have something like this: add_library(libIntern STATIC foo.cpp foo.h bar.cpp bar.h ...) add_library(mylibrary SHARED linkmap) target_link_libraries(mylibrary PRIVATE libIntern mylib1 mylib2 VerData ...) add_custom_command(OUTPUT linkmap COMMAND genmap $ ...) set_property(TARGET mylibrary APPEND PROPERTY LINK_DEPENDS linkmap) But this doesn't work because since libIntern is a static library only the symbols that are referenced somewhere else are included, and no symbols are actually referenced anymore since there are no source files in the library. So then I thought, well, I'll use an OBJECT library for the internal one: add_library(libIntern OBJECT foo.cpp foo.h bar.cpp bar.h ...) add_library(mylibrary SHARED $) target_link_libraries(mylibrary PRIVATE mylib1 mylib2 VerData ...) add_custom_command(OUTPUT linkmap COMMAND genmap $ ...) set_property(TARGET mylibrary APPEND PROPERTY LINK_DEPENDS linkmap) That worked for mylibrary... but of course I can't use $ anymore with an OBJECT library. And I can't use $ in my custom command either. In fact I can't find any way to get a list of the object files that are part of libIntern. So then I finally said "whatever" and created another static library out of the OBJECT library, just for use with my linkmap generating script: add_library(libIntern OBJECT foo.cpp foo.h bar.cpp bar.h ...) add_library(mylibrary SHARED linkmap $) target_link_libraries(mylibrary PRIVATE mylib1 mylib2 VerData ...) add_library(internStatic STATIC $) add_custom_command(OUTPUT linkmap COMMAND genmap $ ...) set_property(TARGET mylibrary APPEND PROPERTY LINK_DEPENDS linkmap) This is not nice but it does work... Except for one thing. Some of the files in foo.cpp ... depend on a header file which is generated as part of the build, using a separate custom command, and I handle this by compiling a little static library that needs this header file: add_custom_command(OUTPUT verdata.h COMMAND ...) set_source_files_properties(verdata.h PROPERTIES HEADER_FILE_ONLY TRUE) add_library(VerData STATIC Version.cpp Version.h) set_property(SOURCE Version.cpp APPEND PROPERTY OBJECT_DEPENDS verdata.h) Then the VerData library is added to target_link_libraries() everywhere. Coming from a strictly makefile background it doesn't seem to me that this should be sufficient, but in fact it appears to work. But in my new setup you can see that the OBJECT library no longer depends on the VerData library, which means that the auto-generated header file is not ensured to be created before the compilation of the objects in libIntern. And in fact, I get compilation errors because the verdata.h file is not generated before these compilations (particularly in Xcode, for some reason). And, I don't know how to solve this problem: I can't find any way to add a new prerequisite to the the libIntern OBJECT library to ensure that the VerData library is built first. I can't add a target_link_libraries() to an OBJECT library. I sure don't want to have to explicitly set the OBJECT_DEPENDS property on every single source file! All I want to do is call a script passing the object files to generate a link map before I create my shared library, and I've gone all the way down this rabbit hole... Help! -- 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] Argh! Thwarted at every turn!
On Fri, 2016-05-20 at 11:58 -0400, Paul Smith wrote: > This is not nice but it does work... Gah! The last of my problems can be solved with add_dependencies(). Somehow I didn't see this and was looking through all the target properties with set_properties() to find a way to add a dependency... sigh. Well, if anyone has a simpler way to solve the basic problem (generating a link map which requires the .o files that will be used to construct the shared library as input) I'm still interested. So in makefile-ese I want to do something like this: mylib.so: $(OBJFILES) linkmap lib1 lib2 lib3 $(CXX) ... -o $@ -Wl,--version-script=linkmap ... linkmap: $(OBJFILES) genlinkmap -o $@ $^ -- 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] cmake 3.5.2 Xcode generator bug
Just discovered a bug in the Xcode generator; this works fine with Makefile generator (on OSX or Linux) and Visual Studio, but fails on Xcode: $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.5) project(BadXcode) add_library(obj OBJECT foo.cpp) add_library(shared SHARED $) $ touch foo.cpp $ mkdir obj $ cd obj $ cmake -G Xcode .. $ cmake --build . The build succeeds, but it never creates the libshared.dylib file: $ find . -name lib\* ./BadXcode.build/Debug/obj.build/Objects-normal/libobj.a I'm not sure why we're creating a .a here, when we're making an OBJECT library, but whatever... the main thing is there's no libshared.dylib: $ find . -name \*.dylib $ find . -name \*shared\* ./BadXcode.build/Debug/shared.build ./CMakeScripts/shared_postBuildPhase.makeDebug ./CMakeScripts/shared_postBuildPhase.makeMinSizeRel ./CMakeScripts/shared_postBuildPhase.makeRelease ./CMakeScripts/shared_postBuildPhase.makeRelWithDebInfo If I use the Makefile generator instead, it works as expected: $ rm -rf * $ cmake .. $ cmake --build . Scanning dependencies of target obj [ 50%] Building CXX object CMakeFiles/obj.dir/foo.cpp.o [ 50%] Built target obj Scanning dependencies of target shared [100%] Linking CXX shared library libshared.dylib [100%] Built target shared $ find . -name lib\* ./libshared.dylib -- 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] cmake 3.5.2 Xcode generator bug
On Fri, 2016-05-20 at 14:34 -0400, Paul Smith wrote: > Just discovered a bug in the Xcode generator; this works fine with > Makefile generator (on OSX or Linux) and Visual Studio, but fails on > Xcode: Meh. Looks like this is documented in add_library(): > Some native build systems may not like targets that have only object > files, so consider adding at least one real source file to any target > that references $. Unfortunately for me, I really have to have all the object files in the OBJECT library (see my previous email about generating linker map files based on the contents), and there're no other files to add into the library. Sigh. -- 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] Cross Compilation & Source file generators
I've got a project with a number of target platforms, including some that I have to cross-compile to such as android, that uses protobuf. If you're unfamiliar, the crux of the issue is that there is both a library, libprotobuf, and an 'compiler', protoc, that takes .proto files and generates a .h/.cc pair that are then included in the project. When cross compiling, want to use the libprotobuf that was compiled on andriod, but the protoc that was compiled for my host environment. How could this be achieved? Currently, my build machine has several different directories where I store the external libraries that have been compiled for the various platforms/compilers that we support (Libraries-arm32, Libraries-x64, Libraries-x64-vc14, ect). Solutions that require modifying protobuf's -config.cmake file are welcome, I've already submitted several PR's improving it. I'd like to establish what the best practice for this kind of situation is as I have the same issue with Flatbuffers. On a slightly unrelated note, is there some way to write something like the AUTOUIC system without modifying cmake itself? It would be lovely if all I had to do was include the .proto file in the source file list. Thanks! Walter -- 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] Cross Compilation & Source file generators
A small addendum - The way I am currently solving this problem is by replacing the version of protoc in the library folder for android with one that works on the host machine, but this is really not the best since it means that the library distribution is tied to the host AND the target. Thinking in terms of concepts, I think I would want a find_package that understood the difference between finding a package for executing and finding a package for linking, but that'd be a pretty fundamental change. On Fri, May 20, 2016 at 7:02 PM Walter Gray wrote: > I've got a project with a number of target platforms, including some that > I have to cross-compile to such as android, that uses protobuf. If you're > unfamiliar, the crux of the issue is that there is both a library, > libprotobuf, and an 'compiler', protoc, that takes .proto files and > generates a .h/.cc pair that are then included in the project. > > When cross compiling, want to use the libprotobuf that was compiled on > andriod, but the protoc that was compiled for my host environment. How > could this be achieved? > > Currently, my build machine has several different directories where I > store the external libraries that have been compiled for the various > platforms/compilers that we support (Libraries-arm32, Libraries-x64, > Libraries-x64-vc14, ect). > > Solutions that require modifying protobuf's -config.cmake file are > welcome, I've already submitted several PR's improving it. I'd like to > establish what the best practice for this kind of situation is as I have > the same issue with Flatbuffers. > > On a slightly unrelated note, is there some way to write something like > the AUTOUIC system without modifying cmake itself? It would be lovely if > all I had to do was include the .proto file in the source file list. > > Thanks! > Walter > -- 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] Cross Compilation & Source file generators
Hi, Did you read the Wiki page about cross compiling with CMake? CMake can already restrict searching for libraries to certain directories when cross compiling. HS Am 21. Mai 2016 04:13:38 MESZ, schrieb Walter Gray : >A small addendum - The way I am currently solving this problem is by >replacing the version of protoc in the library folder for android with >one >that works on the host machine, but this is really not the best since >it >means that the library distribution is tied to the host AND the target. > >Thinking in terms of concepts, I think I would want a find_package that >understood the difference between finding a package for executing and >finding a package for linking, but that'd be a pretty fundamental >change. > >On Fri, May 20, 2016 at 7:02 PM Walter Gray >wrote: > >> I've got a project with a number of target platforms, including some >that >> I have to cross-compile to such as android, that uses protobuf. If >you're >> unfamiliar, the crux of the issue is that there is both a library, >> libprotobuf, and an 'compiler', protoc, that takes .proto files and >> generates a .h/.cc pair that are then included in the project. >> >> When cross compiling, want to use the libprotobuf that was compiled >on >> andriod, but the protoc that was compiled for my host environment. >How >> could this be achieved? >> >> Currently, my build machine has several different directories where I >> store the external libraries that have been compiled for the various >> platforms/compilers that we support (Libraries-arm32, Libraries-x64, >> Libraries-x64-vc14, ect). >> >> Solutions that require modifying protobuf's -config.cmake file are >> welcome, I've already submitted several PR's improving it. I'd like >to >> establish what the best practice for this kind of situation is as I >have >> the same issue with Flatbuffers. >> >> On a slightly unrelated note, is there some way to write something >like >> the AUTOUIC system without modifying cmake itself? It would be lovely >if >> all I had to do was include the .proto file in the source file list. >> >> Thanks! >> Walter >> > > > -- 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
