This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment

Hello GCC and Clang devs!

Unlike the traditional approach of installing system libraries into one
central location like /usr/{lib,include}, the nix package manager [1]
installs each package into it's own prefix
(e.g. /nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev). Moreover,
each package is built in its own environment determined from its
explicitly listed dependencies, regardless of what else is installed on
the system. Because not all package build scripts properly respect
CFLAGS etc., we currently wrap the compiler [2] to respect custom
environment variables like NIX_CFLAGS_COMPILE, so during the build of a
package that depends on zlib and Xlib might have NIX_CFLAGS_COMPILE set
to "-isystem /nix/store/bl0rz2xinsm9yslghd7n5vaba86zxknh-libX11-1.6.3-dev/include -isystem /nix/store/mn9kqag3d24v6q41x747zd7n5qnalch7-zlib-1.2.8-dev/include".

Unfortunately, as you can see if you click through the link or look
through the git history, the wrapper is quite complex (frankly, hacky)
and has evolved mostly through trial and error. Moreover, it's known to
break things like response files [3] and is generally speaking a source
of frustration. I believe the situation would be much improved if gcc
and clang supported some form of "environment-specific" configuration,
either through environment variables or, if absolutely necessary,
command line flags that can be passed unconditionally (note, for
example, that we currently parse the cc command line to see if we're
going to do any linking before deciding to pass in linking-specific
options) and clearly have the semantics we want. Ideally we would be
able to specify something on the level of abstraction of "this directory
should be treated like you would normally treat /usr" and get
e.g. /include, /lib, frameworks on OS X, etc. handled properly.

Would patches aimed at achieving this be considered for inclusion
upstream? My current thought for a first step would be an environment
variable specifying a file with command line flags that are ignored by
the compiler driver in contexts where they are inapplicable or
overridden by other command line flags, but I'm definitely open to
guidance on how this should best be achieved from your perspective. I'm
happy to do the work needed to get this in place if there is interest,
please let me know!

Shea Levy


Attachment: signature.asc
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]