<div dir="ltr">Perhaps it'd make sense to just have one such environment variable entry point - perhaps in Clang's driver (& it'd use the environment variable as part of constructing the -cc1 command line - thus crash reports, etc, would still encode everything needed for reproducing the failure). Ensuring that all the options/configuration points are exposed at least via -mllvm style cl options (these are cheap to add - don't have to be plumbed through all the different layers, etc - intended for compiler-engineer tweaking/experiments/investigation).<br><br>& that means not having lots of environment variable reading/testing all over the codebase, so probably not much need for generic/helper utilities</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 7, 2018 at 7:59 AM David Greene via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sure, but we're not using this with ccache and other such things. We're<br>
very specifically using them for debugging purposes. It's very<br>
special-case and so we don't expect them to interact well with general<br>
tools. They're not meant for day-to-day use.<br>
<br>
-David<br>
<br>
Bruce Hoult <<a href="mailto:brucehoult@sifive.com" target="_blank">brucehoult@sifive.com</a>> writes:<br>
<br>
> Env vars that change compiler output make it impossible to write tools<br>
> such as ccache or distcc. Including the entire env in the hash value<br>
> that determines whether ccache has a cache hit (as well as the<br>
> compiler command line and the preprocessed source file) would be<br>
> ridiculous and would result in very few cache hits.<br>
><br>
> On Thu, Sep 6, 2018 at 11:34 AM, Matthias Braun via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I can definitely relate to third party Makefiles being a huge pain<br>
> to manipulate. And env vars can be an okay tool to help debugging<br>
> (see also CCC_OVERRIDE_OPTIONS in clang for example). I also don't<br>
> want to dispute that they may be the right solution in some cases.<br>
> That said in my opinion we should not make it look like using<br>
> environment variables is a good or encouraged thing because there<br>
> are downsides:<br>
> <br>
> - The bug reproducetion instruction and file bundles that clang<br>
> produces when it crashes does not show environment variables,<br>
> meaning you possibly cannot reproduce a bug...<br>
> - Similarily when producing .ll files, going through jenkins<br>
> output, etc. You typically have no good way to see the environment<br>
> variables in effect. Even if you do, there are typically hundreds<br>
> of them and it may be hard to know which ones affect the compiler.<br>
> - env vars only work more reliably if they are sparsly used as<br>
> soon as they have interesting/desirable effects you will see<br>
> people using them in their makefiles as well, making the whole<br>
> thing brittle again because now you have to wonder if someone<br>
> overrides, resets, manipulates the env vars in their makefiles<br>
> bringing you back to square one where you have to understand and<br>
> change complex third party makefiles...<br>
> <br>
> - Matthias<br>
> <br>
> <br>
> <br>
> > On Sep 6, 2018, at 10:44 AM, David Greene <<a href="mailto:dag@cray.com" target="_blank">dag@cray.com</a>> wrote:<br>
> > <br>
> > Yes, but in your example getenv is called every time<br>
> enableFooBar needs<br>
> > to be initialized. What if your code is itself wrapped inside<br>
> another<br>
> > loop you can't see (for example, the PassManager invoking<br>
> passes)?<br>
> > <br>
> > Maybe I'm being overly pedantic.<br>
> > <br>
> > We use a lot of environment variables in our compiler because<br>
> it's<br>
> > really super annoying and takes a lot of developer time to have<br>
> to<br>
> > update customer Makefiles to include the debugging options we<br>
> want to<br>
> > use to debug customer problems. These are huge customer codes<br>
> with<br>
> > often many Makefiles which may be generated by custom tools we<br>
> don't<br>
> > understand at all. :) It's much easier to use the compiler flags<br>
> that<br>
> > are in the Makefiles and set some environment variables to<br>
> override<br>
> > things during "make."<br>
> > <br>
> > It seems odd that cl::ParseEnvironmentOptions exists but there<br>
> is no<br>
> > "official" way to get at environment variables.<br>
> > <br>
> > If this isn't something the community wants or needs, that's<br>
> fine. I<br>
> > was just asking if a contribution would be welcomed if we end up<br>
> > developing something.<br>
> > <br>
> > -David<br>
> > <br>
> > Matthias Braun <<a href="mailto:mbraun@apple.com" target="_blank">mbraun@apple.com</a>> writes:<br>
> > <br>
> >>> On Sep 6, 2018, at 7:09 AM, David Greene via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> >>> <br>
> >>> Ok, thanks! I'm not dealing with UTF-8 so I don't think<br>
> Process::GetEnv<br>
> >>> will work. I was looking for something that caches calls to<br>
> getenv so<br>
> >>> checks could be put into tight(-ish) loops without too much<br>
> performance<br>
> >>> impact.<br>
> >> <br>
> >> Sorry for the snarky answer but we already have that:<br>
> >> <br>
> >> // outside of loop<br>
> >> bool enableFooBar = getenv("ENABLE_FOO_BAR");<br>
> >> while (...) {<br>
> >> // it's not getting re-checked every loop iteration:<br>
> >> enableFooBar;<br>
> >> }<br>
> >> <br>
> >> Generally we don't really look at env vars today (I think for<br>
> clang<br>
> >> you can mostly affect some search paths with them) and IMO it<br>
> is a<br>
> >> good thing to force being explicit on the command line<br>
> instead...<br>
> >> <br>
> >> - Matthias<br>
> >> <br>
> >>> <br>
> >>> -David<br>
> >>> <br>
> >>> Reid Kleckner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
> >>> <br>
> >>>> llvm::Process::GetEnv looks like it does the right thing.<br>
> >>>> <br>
> >>>> I think we added it to deal with Unicode on Windows, though.<br>
> We have<br>
> >>>> plenty of calls to getenv that are mostly looking for '1', '<br>
> 0', or<br>
> >>>> variable presence, and they pretty much work.<br>
> >>>> <br>
> >>>> On Wed, Sep 5, 2018 at 2:12 PM David Greene via llvm-dev<br>
> >>>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> >>>> <br>
> >>>> Is there an LLVM-ish way to handle environment variables?<br>
> >>>> Specifically,<br>
> >>>> I want to check existence and/or value of an environment<br>
> variable<br>
> >>>> and<br>
> >>>> take appropriate action.<br>
> >>>> <br>
> >>>> I was kind of surprised that LLVM doesn't seem to have any<br>
> >>>> special/optimized way to deal with environment variables. The<br>
> one<br>
> >>>> Stackoverflow I found on it suggested using getenv().<br>
> >>>> <br>
> >>>> Thanks!<br>
> >>>> <br>
> >>>> -David<br>
> >>>> _______________________________________________<br>
> >>>> LLVM Developers mailing list<br>
> >>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> >>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>>> <br>
> >>>> _______________________________________________<br>
> >>>> LLVM Developers mailing list<br>
> >>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> >>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>> _<br>
> ______________________________________________<br>
> >>> LLVM Developers mailing list<br>
> >>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> >>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>