[Geany-devel] Missing environment variables for builds and executes

[Lex Trotman]

On 26 November 2010 07:44, Chow Loong Jin <hyperair at gmail.com> wrote:
> On Thursday 25,November,2010 03:43 PM, Lex Trotman wrote:
>> On 25 November 2010 16:09, Chow Loong Jin <hyperair at gmail.com> wrote:
>>> On Thursday 25,November,2010 03:06 AM, Enrico Tröger wrote:
>>>> On Wed, 24 Nov 2010 10:15:00 +0800, Chow wrote:
>>>>
>>>>> On Wednesday 17,November,2010 10:40 AM, Lex Trotman wrote:
>>>>>> Hi,
>>>>>>
>>>>>> When Geany is started from the Gnome menu it doesn't get environment
>>>>>> variables set in .profile, .bashrc etc.  Other window managers seem
>>>>>> ok.
>>>>>>
>>>>>> This means that builds don't see CFLAGS, python executes don't see
>>>>>> PYTHONPATH etc :-(
>>>>>>
>>>>>> Although builds and executes run in shells, a non-interactive shell
>>>>>> does not load any startup files.
>>>>>>
>>>>>> The attached patch adds the option (-l) to run the build and execute
>>>>>> shells as login shells which will load startup files.
>>>>>>
>>>>>> Two hidden prefs build_in_login_shell and exec_in_login_shell allow
>>>>>> you to disable this for builds or executes respectively if running
>>>>>> your startup scripts causes some problem.
>>>>>
>>>>> Hi,
>>>>>
>>>>> I actually believe that on some distros .bashrc/.profile is sourced by
>>>>> default on gdm, and on others, .xprofile is used for this purpose. I
>>>>> don't think a login shell or interactive shell should be used for this
>>>>> purpose though.
>>>>
>>>> I agree completely.
>>>> If Ubuntu messed up with their system, it's their problem. Why should
>>>> we fix Ubuntu's or Gnome's mistakes in Geany?
>>>> In other, less harsh words, I think an applicaton should not fix the
>>>> problems in the outer environment.
>>>>
>>>> Lex, above you said yourself, other window managers (I assume other
>>>> than metacity or compiz), work ok. So, that's a pretty good argument to
>>>> *not* fix it in Geany.
>>>>
>>>> And yes, I noticed you already solved the problem for your system :).
>>>
>>> This isn't a window manager problem, it's a session manager problem. Also,
>>> sourcing .bash_login/.profile on GUI login is retarded behaviour,
>>
>> Maybe, but how then are environment variables supposed to be set?
>> Remember in this case they are for non-GUI applications invoked from
>> the GUI.
>
> Interactive shells will have their own dot files like .zshrc and .bashrc.
> Non-interactive shells will inherit the environment from their parents, and
> their parents will probably inherit it from the session manager, which will
> source ~/.xprofile.
>
> In order to have a single point of configuration, I'd do something like:-
> cat > ~/.env <<EOF
> export CFLAGS=blah
> export LDFLAGS=blah
> export ANYTHINGELSE=blah
> EOF
> echo . ~/.env >> ~/.$shellrc
> echo . ~/.env >> ~/.xprofile
>
> Then I'd just configure my environment variables in ~/.env and be happy.
>
> I don't really see this whole issue as a problem, really. Just ~/.xprofile not
> being widely known.

Which is actually the problem!! Its not documented.  Should be in man
xsession where ~/.xsession etc are documented.

 A quick google search shows that ~/.xprofile appears to be
> pretty standard across distributions, too, so Enrico, this behaviour isn't
> broken or anything, it's pretty much standard. If your distribution doesn't
> support ~/.xprofile, then your distribution's broken.

It can't be considered standard until documented somewhere that makes
it a promise by the system, to date its just common, not standard.

>
> On the other hand, I mentioned providing a configuration interface for setting
> build environment variables because I thought it might be useful if you need
> different flags for different projects, rather than all of them using the same
> set of flags whereby you can stuff them in some dot file.
>

True, but in practice how often would it be used.

The things different projects need different (eg optimisation/debug)
would/should be set where make will notice them change rather than in
an environment variable.  That way they "should" trigger make to
re-compile. I don't really advocate using CFLAGS to pass options to
compilers since changes won't cause make (or any other builder that I
know of) to re-run.

The thing that actually caused problems was PYTHONPATH since the build
script couldn't find its library, and PATH would likely be another
problem for executes.  But these can safely be shared by all.

Cheers
Lex

> --
> Kind regards,
> Loong Jin
>
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>