[CMake] Preventing CMakeLists from being too similar
Daniel Wirtz
daniel.wirtz at simtech.uni-stuttgart.de
Mon Jul 6 09:30:54 EDT 2015
Hey,
there's several options.
- the easiest is probably to create inclusion files on the Nick level,
put the identical functionality in there and include them in the modules.
- a bit "cleaner" ist to create a e.g. Macros.cmake file on the Nick level,
put the identical functionality in there and invoke the macros from the
sub-level;
that's more like a "separation of concerns / encapsulation" approach.
- if your modules need to be self-contained (without knowing to be
inside the "Nick" folder),
you could think of setting up a template on Nick level and have that
being configured into the module
folders with appropriate different values inserted.
i'd go for the second option myself.
cheers
Daniel
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a
+49 711 685 60044
On 07/06/2015 02:41 PM, Crast, Nicholas wrote:
>
> Hi guys,
>
> I have a question for you about general practices. I have a top level
> directory with a bunch of modules inside:
>
> Nick
>
> |
>
> |module1
>
> |module2
>
> |module3
>
> Module1, module2, and module3 are subdirectories inside of the nick
> directory. Each module directory contains src,inc and test (gtest unit
> test files).
>
> These modules are pretty similar in structure, meaning the CMakeLists
> files are almost identical. Is there any way to make some sort of
> generic CMakeLists file that I can call with arguments for all 3
> modules? I’m having the same issue with unit tests, where the unit
> test section for my CMakeLists is essentially identical between the
> modules.
>
> Thoughts?
>
> -Nick
>
> ----------------------------------------
>
> Nick Crast
>
> Software Engineer
>
> Saab Sensis Corporation
>
> Phone: 315-445-5703
>
> Email: Nicholas.Crast at saabsensis.com
> <mailto:Nicholas.Crast at saabsensis.com>
>
>
> /This message is intended only for the addressee and may contain
> information that is company confidential or privileged. Any technical
> data in this message may be exported only in accordance with the U.S.
> International Traffic in Arms Regulations (22 CFR Parts 120-130) or
> the Export Administration Regulations (15 CFR Parts 730-774).
> Unauthorized use is strictly prohibited and may be unlawful. If you
> are not the intended recipient, or the person responsible for
> delivering to the intended recipient, you should not read, copy,
> disclose or otherwise use this message. If you have received this
> email in error, please delete it, and advise the sender immediately. /
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150706/72de2dd8/attachment-0001.html>
More information about the CMake
mailing list