[cfe-dev] Configuration files

[Serge Pavlov via cfe-dev]

2017-03-16 9:46 GMT+07:00 James Y Knight <jyknight at google.com>:

>
> 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?
>

Initial versions of this proposal defined two kinds of config files:
- named, which should be explicitly specified by a user by option --config
or be encoded into executable name as `armv7l-clang`.
- default, which is loaded always much like `.bashrc` or any similar file.
These two kinds of config file shared implementation but addressed
different use cases, which made confusion during discussion. To facilitate
review process the support of default config files was removed from the
proposal. The issues you mention should mostly be solved by the default
config files.

If the default config files were implemented in clang, driver would search
binary directory for default configuration description. If compiler is
named as `armv7l-clang`, driver first tries file `armv7l.cfg` then
`clang.cfg`. If config file is found, options listed there are put into the
set of driver arguments before any option specified in command line.

With this feature a distribution or SDK can supply set of config files as a
part of clang package and tunes compiler appropriately.


> 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).
>
>
Each supported target can have separate config file.


> 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?)
>
>
Default config in sysroot could be included by default clang config,
however driver must know where the sysroot is. We could support a set of
macros, for instance expand `$TARGET` in config file to target name as
 `armv7l-clang`. This topic is not elaborated yet.


> 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?
>
>
To specify a target looks like a more flexible solution. "$TARGET-clang"
symlink method was already implemented in early versions of
https://reviews.llvm.org/D24933. It is possible also to extend treatment of
`--target` so that it acted similar to `--config`.

Thanks,
--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170316/d2f82491/attachment.html>