CMakeList.txt for a third-party external module

RE: CMakeList.txt for a third-party external module

zhouwb — Fri, 02 Jun 2023 01:52:40 GMT

Hi:

Thanks for your answer!

[quote userid="103347" url="~/f/nordic-q-a/100015/cmakelist-txt-for-a-third-party-external-module/428711"]Using add_subdirectory() is what I am used to, and what I consider the formal way.[/quote]

Ok, I see.

[quote userid="103347" url="~/f/nordic-q-a/100015/cmakelist-txt-for-a-third-party-external-module/428711"]Have you gotten any further on this?[/quote]

As my previous post, I considered two candidates ways:

(1) set zephyr build options to target_build_options, then add_subdirectory;

(2) declare the module as zephyr library and add all module source files to zephyr_library_sources.

For (1), it didn't go very smoothly, so I gave it up.

I use (2) and it works for the present.

Maybe this is a case_by_case issue, so I want to close this issue.

I am not familiar with rules in this nordic devzone, if I need do something to close, please notify me.

Thanks!

RE: CMakeList.txt for a third-party external module

Elfving — Thu, 01 Jun 2023 11:47:57 GMT

Hello again, and sorry about the delay

It would be easier to consider this if you had a problem getting something to work the way you wanted it to. Using add_subdirectory() is what I am used to, and what I consider the formal way.

For an example of it being used in a larger project with submodules I would recommend taking a look at the Asset Tracker application sample.

Have you gotten any further on this?

Regards,

Elfving

RE: CMakeList.txt for a third-party external module

zhouwb — Wed, 24 May 2023 02:07:38 GMT

Hi Elfving:

[quote userid="103347" url="~/f/nordic-q-a/100015/cmakelist-txt-for-a-third-party-external-module/426937"]Could you expand a bit on this? What do you find difficult if the module was too big?[/quote]

There is no difficulty really happens for the present. I "imagined" some difficulties( seems inconvenience is proper):

(1) The 3rd-party module rely on a header file which is generated at build time;

(2) One C source file in the 3rd-party moddule depends on another C source file, then I must understand the dependices.

(3) ... ...

If I use the cmake system in the 3rd-party module, these problem will be resolved by the system itself.

Now if I try to define the build rules for the module in my cmake system, I must handle these problems.

As my previous post, I googled some examples that does re-defined the build rules, bypassing the 3rd-party module's cmake system. It make me doubt the meaning of the 3rd-party module provide the cmake system.

I am now investigating if it is possible to write my CMakeLists.txt¹ like below "fake" code:

target_compile_options(${3rd_party_module_target}, ${ZEPHYR_COMPILE_OPTIONS})

add_subdirectory(a_third_party_software_module_dir)

Please let me know your opinions.

Thanks!

RE: CMakeList.txt for a third-party external module

Elfving — Tue, 23 May 2023 12:49:33 GMT

Hello,

[quote user=""]Which means the build system in the third_party dir is not used. I think this is difficult when the third_party module is too big.[/quote]

Could you expand a bit on this? What do you find difficult if the module was too big?

Regards,

Elfving