[vlc-devel] [PATCH] contrib: unexport env variables when cross-compiling

Rémi Denis-Courmont remi at remlab.net
Thu Oct 3 17:35:07 CEST 2019


Le torstaina 3. lokakuuta 2019, 16.00.00 EEST Alexandre Janniaux a écrit :
> Hi,
> 
> IMHO, there __is__ a special case around some variables anyway, because
> you can find them in the toolchain file as well, and should only use
> them from there as they are expected to be correctly set and parsed, even
> from user input.

By that logic, all variables that have an effect on the build system are 
special, and all should be unexported. There are plenty of other variables 
that have an effect, and yet this patch does _not_ unexport then: PATH, 
LD_PRELOAD, LD_LIBRARY_PATH, LANG, LC_*, IFS...

And those with no effects could evidently be unexported too. So really, there 
is no special case here - with your logic, all variables should be unexported. 
That argument seems absurd.

The only case where you really need unexport is if you need a variable to be 
undefined. I can see the point for some job management variables. I have yet to 
see an explanation why any of the proposed variable here needs to be 
*specifically* undefined.

> For instance, what we do with HOSTVARS is exactly because there is no
> toolchain file for autotools (or others, or it doesn't behave the same) and
> that we want to export precise variations of these inputs.

There are no needs to export variables to autotools. If/when --build & --host 
are insufficient, you can pass values as command line arguments, as opposed to 
environment variables. Ditto make(files).

> Other variables can be set, we don't care because we don't have to know,
> but these are special variables that are already taken into account by
> the build system. Taking them into account twice, potentially with different
> values can only be harmful.

You also get different build results with different locale settings in the 
environment. I've seen real life build system that even conditionally crashed 
depending on the locale.

Again, if the argument is that potentially variables that affect the build are 
harmful, then all variables are harmful.


For this reason, I am against this patch until somebody proves that it is 
necessary and correct.

-- 
Rémi Denis-Courmont
http://www.remlab.net/





More information about the vlc-devel mailing list