1 |
As many of you probably know, ago@ has been expanding the scope of our |
2 |
CFLAGS/CC support to include some other common build variables: |
3 |
|
4 |
* CC |
5 |
* CXX |
6 |
* AR |
7 |
* CPP |
8 |
* NM |
9 |
* RANLIB |
10 |
* AS |
11 |
* LD |
12 |
|
13 |
Some of those are POSIX standards[0], |
14 |
|
15 |
* CC |
16 |
* AR |
17 |
|
18 |
Others are de-facto GNU make standards[1], |
19 |
|
20 |
* CXX |
21 |
* CPP |
22 |
* AS |
23 |
|
24 |
and a few are de-facto GNU libtool standards[2]: |
25 |
|
26 |
* NM |
27 |
* RANLIB |
28 |
* LD |
29 |
|
30 |
If we expect them all to work properly in Gentoo, we have to agree on |
31 |
what they mean, and thus how they should be injected into build systems. |
32 |
For example, we had a problem with sci-mathematics/pari, whose upstream |
33 |
is using the LD environment variable for something other than what GNU |
34 |
libtool uses it for. With LD set to something libtooly in the |
35 |
environment, the pari build fails. We can solve that by unsetting LD in |
36 |
the ebuild, but for that to be The Right Thing To Do, we should be |
37 |
expecting LD to contain something libtooly, and thus something |
38 |
inappropriate to be passed to the pari build. |
39 |
|
40 |
To avoid these issues, I suggest creating a list of "Gentoo environment |
41 |
variables" in the devmanual with descriptions of how they should be used |
42 |
and pointers to the references (for why we chose that meaning). That way |
43 |
a user can export LD, for example, and know that it will be used how he |
44 |
thinks it will be used. |
45 |
|
46 |
|
47 |
[0] https://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html |
48 |
|
49 |
[1] |
50 |
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html |
51 |
|
52 |
[2] https://www.gnu.org/software/libtool/manual/libtool.html |