[CMake] Specifying different compilers for subsets of a project

[George Zagaris]

Hi Chuck,

Thanks for your e-mail.

Yes, the different build directory strategy is definitely the clean way to
do this.

However, it is my experience that folks not familiar with CMake tend to get
a knee-jerk reaction when required to configure and build seperately.
Especially, when something like this is more easily hacked in raw
Makefiles, for example. Hence, I am investigating various alternatives to
contrast with the nominal separate build directory strategy.

I really like the custom target suggestion -- makes perfect sense.

Best,
George

On Thu, Oct 16, 2014 at 11:32 AM, Chuck Atkins <chuck.atkins at kitware.com>
wrote:

> Hi George,
>
>
>> The obvious way to compile front-end tools is to create another
>> directory, e.g., "front-end-build" and run cmake therein to re-configure
>> and build with a front-end compiler.
>>
>
>> However, since only a relatively small subset of the files needs to be
>> compiled for the front-end, it is desirable to do this within the same build
>>
>
> This is a common case that occurs when cross compiling where certain
> targets are used to generate files used in the rest of the build.  Using
> different build directories is the typical way, but you can reduce the host
> build as much a possible by creating a BuildTools or CrossTools custom
> target with depends only on the targets needing to be build on the host
> system. This way, you can build only the subset needed on the host and in
> the cross-build, just point the host build directory.  This is how both VTK
> and ParaView do it.
>
> Trying to specify multiple compilers isn't so straight forward.  Consider
> the entire platform that goes in to cross compiling: you have the entire
> build toolset, but then you also have the entire find infrastructure that
> needs to look in different places for includes and libraries.  There's an
> entire stack of variables, tools, and settings that are needed to build on
> a given platform and you would basically need a whole duplicate set
> generated from a secondary configure run to make it work in the general
> case.  This is what is effectively happening anyways in the two-builds
> scenario.
>
> - Chuck
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141016/c3bdaa77/attachment.html>