Re: "features" problems

[Carnë Draug]

On 20 March 2016 at 19:20, Philip Nienhuis <address@hidden> wrote:
> Carnë Draug wrote:
>> [...]
>>
>> That solution has another advantage.  PKG_ADD is sourced.  This means that
>> if anything in PKG_ADD generates a result it will replace local variables
>> (clearing variables at the end of PKG_ADD does not restore their value).
>
>
> Yes, I know PKG_ADD runs in the current scope; io package's PKG_ADD is
> careful and cleans up after itself.

It does not restore the original user variables.  If the user had variables
named:

    libdir spr_status userdir homedir bnam ooopath ii HAVE_JAVA amd64y

they will have been removed after loading the io package.

>> The reason for why PKG_ADD behaves like this is that it is meant for
>> simpler
>> things, such as registering options.  If you need a complex piece of code,
>> use a separate function for it and call it from PKG_ADD.
>
> That is a good suggestion.
> But it doesn't change the PKG_ADD location issue which was at the base of
> this part of the discussion - to wit, why certain octave_config_info output
> could be required.
>

It does.  Instead of writing another long email trying explaining this, I
just did the coding myself.  See bug #47480 and the attached patch.

This should drop all your requirements on the paths currently being served
via octave_config_info.  If so, most of the discussion above becomes
irrelevant which is why I'm not addressing it.

Carnë