[cmake-developers] [CMake] dependencies of cross compiliations

[Eric Noulard]

Le mar. 11 déc. 2018 à 14:18, Rolf Eike Beer <eike at sf-mail.de> a écrit :

> Eric Noulard wrote:
>
> > When ones do cross compile for the host + one or several target a
> > lighter
> > "add_superbuild" API could be design. I'll try to think about it more
> > thoroughly and do some proposal. Ideally we shouldn't need to provide
> > many
> > parameters beside the toolchain and a way to specify "the host build".
>
> I guess putting the host-build location in the toolchain file could be
> one way
> to just get it done. In case one has multiple builds that should share
> one host
> build then just set an absolute location, and if you don't it will be
> below your
> normal build directory.
>

Yes that seems a reasonable way to do it.

There are just 2 things that scare me a bit off: we surely want a way to
> break
> that into smaller pieces so we can introduce it over multiple releases,
> maybe even
> as a tech-preview so we can break things if we see that we have not
> taken a bigger
> usecase in account, and I currently don't see the points to slice that
> up.
>

We could add new builtin command along with an enable_preview command that
would bring the currently in preview commands.
If you don't call enable_preview CMake will issue an error telling that the
command you are trying to are in "preview" if it's the case.
When enabling preview you'll get the "in-preview" command plus a warning
telling you that enabling preview brings you command/features that are not
guaranteed to be backward compatible.

Equipped with that we could incubate a feature and switch it from preview
to prime-time when we are confident about it.


> And we really, really want a
> .cmake_no_freaking_in_source_build_under_any_circumstances
> or however we gonna call it, and we need that first. There has been
> wasted enough time
> with in-source builds, missing cleanups and all the weird side effects
> in our industry
> for decades, and sadly CMake hasn't stopped that nonsense entirely.
> There are still
> projects out there that can only build this way because they do some
> assumptions on
> where to pick up files, but for something that will end up mixed
> cross/host build this
> will never under any circumstances going to work.
>

Yeah you are damn right, and guess what, I was convinced by that near a
decade ago from now
https://cmake.org/Bug/view.php?id=6672 !!

The old ticket got reloaded in the "new" tracker as
https://gitlab.kitware.com/cmake/cmake/issues/6672


> I wonder if we can't just add it as extra argument to
> cmake_minimum_required(), in a
> way that you _have_ to specify ALLOW_IN_SOURCE_BUILD explicitely if you
> require a version
> newer than say 3.14, so anyone that is not explicitely requesting this
> to work will
> automagically end up in a "clean" setup. Of course we need to make sure
> that no file is
> written by CMake until that line is parsed (or any other command is
> encountered). Or
> simply do something similar when using toolchain files, which CMake can
> detect before
> even start parsing the main CMakeLists.txt.
>

There is two problems here.

1) AFAIR (there is some discussion about that in the old ticket) as soon as
CMake is parsing CMakeLists.txt it creates the CMakeCache.txt and you want
to avoid polluting the source before that thus the proposal from Ben & Brad
to add the no-in-source enforcement in an extra file.

2) Changing the default behavior of not accepting in-source is good for me
but it is clearly backward incompatible. Unless I'm wrong there has not
been any such backward-incompatible change in CMake as of now.
    I doubt this would be widely accepted. Or may be for CMake 4.


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake-developers/attachments/20181211/585fecab/attachment.html>