[cfe-dev] Configuration files

[James Y Knight via cfe-dev]

On Tue, Mar 14, 2017 at 3:08 PM, Hal Finkel via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 2. More elaborated solutions
>
> Many are of opinion that config file in this form is too primitive
> solution, for instance:
> - A good solution must be able to deduce target from arguments (-m32),
> - Any workable config-file scheme *must* interact with the various target
> specification command-line arguments, and allow for setting options
> dependent upon the actually-selected target,
> - Config file must reduce complexity of clang driver.
>
> The presented implementation of config files is only a way to specify set
> of options, it cannot solve these problems. However it can be extended in
> future so that, for instance, the following construct could be allowed
> (particular syntax does not matter):
>
>     …
>     #if (argv.contains("-m32"))
>     -target i686-unknown-linux-gnu
>     #else
>     -targer x86_64-unknown-linux-gnu
>     #endif
>     …
>
> This syntax would require to support `if/else/endif` control construct,
> and builtin function `argv.contains`. Ability to include an option
> conditionally is likely to be sufficient to solve large part of the
> problems mentioned above and can indeed reduce complexity of the driver.
>
>
> This is appealing, but I think that we really need to be careful here. We
> don't want to create a system where people are encouraged to replicate
> complex driver logic in the config files in order to independently figure
> out which features might be enabled. Of course, we already do this, but the
> logic ends up in wrapper scripts (and is just as likely to be broken, if
> not more so). However, if we're going to create a solution here, we should
> do so in a way that does not encourage the confg-file writer to duplicate
> driver logic.
>


I'd really like to at least have a *design* for how this can eventually
incorporate target-specific options before moving forward with adding a
--config option, even if the initial commit won't implement the full design.

I don't believe hand-wavy "maybe we'll add syntax that looks kinda like a
comment so older versions will ignore it" is good enough there.

I'd like to again keep in mind the use-case I mentioned a while ago.
Approximately every linux distro configures GCC to set their default target
cpu levels. E.g., Debian seems to set the following:
- On x86, the default CPU should be i686.
- But on x86-64, the default CPU isn't changed (aka it's left as "x86-64").
- For ppc32/ppc64, the default CPU should be power7 but tune for power8.
- For ppc64le, the default CPU should be power8.
- On ARM (hf), armv7-a should be the default cpu, vfpv3-d16 the default
fpu, and it should default to thumb mode.
etc...

Note that those defaults are different on different releases of the distro.

The way you do this with GCC is via options passed to the configure script:
--with-arch-32= --with-arch-64= --with-fpu= --with-mode= etc. which turn
into values used in the target-specific OPTION_DEFAULT_SPECS macro. Since
GCC only builds for one target at a time (or two, if you count 32/64
separately), and you're expected to need to build a new gcc any time you
want to cross-compile, that's sufficient.

Clang is intrinsically a cross-compiler, so gcc's solution isn't good
enough for clang (nor is clang's current behavior enough). So, what's the
plan to actually solve this?

1. There needs to a way to be able to configure the defaults for all
supported architectures of the platform (either in a single config, or in
multiple that clang knows how to select).

2. Those platform defaults should, somehow, avoid interfering with the use
of clang to cross-compile TO a different platform, and be easy to use FROM
a different host platform. (find default config via sysroot, maybe?)

3. How do we recommend users select a target?
Do we need to look for the proper defaults when the user specifies
"--target $TARGET" to clang?
Or maybe we favor of the "$TARGET-clang" symlink method?
Or maybe "--target" is a low-level feature not recommended for end-users,
and we should steer people to using something like "-arch", to select a
named architecture within the current platform configuration, like apple
does with darwin-based platforms now?

Again, I'm not saying the first patch needs to implement everything, but I
do think a design should exist on how this is going to work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170315/e96afa5e/attachment.html>