[Lazarus] Lazarus config woes

[Hans-Peter Diettrich]

Martin schrieb:

> ...let me explain a bit more what I tried to explain before (and had in 
> my last mail too)
> 
> It would only help, if you totally abandon all global config. don't even 
> look for a global anymore, only check the exe folder, nowhere else.

Why that?

When multiple directories are in a search path, the search stops on the 
first item (file...) found. That's common practice, isn't it?

> But if  the search order for config would be:
> - exe-dir
> - global as current
> 
> Then as soon as a global config exist you are back to were you are now.

Something seems to be wrong with your list. Mine looks like this:
1) explicit -pcp
2) EXE dir (meaning the Lazarus dir from which the EXE was built)
3) global dir


> - download a new lazarus, into some folder "lazfoo"
> - now lazfoo does not yet contain config, but the global folder does.
> 
> so in your way, one has to first create a config in lazfoo.
> This is an explicit action the user must undertake, same as adding the 
> -pcp.

The IDE already *is* clever enough to handle non-existing or 
inappropriate configs. Remains only to specify where the updated config 
should be stored.

> => But if the user is unaware of the issue, he will not ad that config 
> to lazfoo, and run with the global config => same as now

When no global (default) config exists, the new config (eventually) can 
be stored there, else the obvious place is the Lazarus(~EXE) directory.


> Let me guess, now you say, then every lazarus should come with a local 
> config?
> That is the same as abandoning the global config completely (because if 
> always a local conf exists, it will always use the local, never the 
> global) => but the proposal was an optional local, that would be found 
> first, if and only if present.

Perhaps we should separate two cases:

1) When the IDE can determine the Lazarus directory to use, then the 
entire (remaining) config *can* be stored in a common place. This 
applies at least to Windows.

2) When the IDE can *not* determine this, it must either look into an 
common place, or a pcp must be supplied on every invocation. This seems 
to apply to Linux?

Case [2] deserves no further considerations, no automatism can be added. 
But this is not a valid argument to force the users of more comfortable 
systems <BG> to suffer from poor UNIX functionality.


> So were (or how) exactly, in which scenario, does an additional search 
> for a local config actual help the unaware user?

The IDE can keep certain (required) modifications in the local config, 
e.g. an non-standard FPC required to compile this version. This compiler 
may be part of the installation, what's just the default in Windows 
installations.

> Sure, once you know,it may be more convenient to some, but a startup 
> script is no less convenient to most.

I have no problems with startup scripts, as long as I do not have to 
write them myself, must remember where I placed and how I named them, 
etc. ;-)

But I have a BIG problem with non-shareable configs. When I have to 
configure manually every new Lazarus installation, because it is too 
stupid to configure itself, or it overwrites the configs required for my 
other installations, then something is wrong :-(

Concrete example:
After every Lazarus checkout a couple of adaptations are required.

- For the bootstrap I have to update the PATH, to include the required 
compiler and tools, before I can invoke "make all". This is the point 
where that compiler *could* become the default for *this* installation.

- Next I *must* copy a config from somewhere else, create a desktop 
icon, and add the -pcp to it.

- Then, in the first run of the new IDE, I have to update the pathes to 
the Lazarus and compiler directories, copied from the old config. Then I 
must exit and restart the IDE, so that I can hope that it uses the 
updated config.

This may look not very complicated, but on the next checkout I have to 
remember all the details, what must be updated manually etc.

DoDi