[Lazarus] Lazarus config woes

[Hans-Peter Diettrich]

Martin schrieb:

> But that is only where to search:
> - That is: IF there was a config in the local director, then yes maybe 
> it would be good to use this local config

That's what I want.

> - Except: people who had lazarus for a long time, and kept upgrading, 
> may still have an old 0.9.24 config there => and that may be very 
> outdated, so that would not be good either.

The config typically is updated on every IDE termination. I don't see 
how that would cause problems. In contrast *automatic* use of *newer* 
configs will prevent recompilation of the IDE, due to breaking changes 
in the FPC.


> It doesn't solve the problem for newbies.

Which newbie problems are solved with the current procedure?


> An SVN checkout has no config files in the beginning.

In which case the old (common) config will be used - with unknown 
outcome. On my working system the default config stems from 0.9.28 (FPC 
2.2.4), and consequently is unusable with newer Lazarus checkouts. 
Newbies may have that problem with outdated installations, too.

> So if the IDE starts without any config file (let's assume, there are 
> none in the default location either); then the IDE must decide where to 
> create them.
> And that is in the default location.

An SVN checkout has no IDE/EXE, so that it must be built using Make. The 
settings for FPC and the current directory should be enough to build a 
new config, in the current directory.

> Defining some rule where new config will be autocreated, sometimes here, 
> sometimes there... IMHO the worst idea ever...

ACK, the simplest solution should take into account all real-life cases.

> So, even if the IDE was scanning the local dir first, users who want 2 
> or more installs would have to know that they must hand-create (or 
> otherwise force) this local config before they use the 2nd install. 
> (currently it is knowing the --pcp switch).
> Either ways, users who do not know, will be in trouble...

Let's separate the corner cases:

1) Installation from distribution packages (snapshot, deb, rpm)
---------------------------------------------------------------
The installation may end up in a privileged directory, what IMO is a bad 
idea. The Windows installer (and snapshots) already install Lazarus in a 
non-standard directory (C:\Lazarus), just to prevent trouble with access 
rights. The same could be made the standard on other platforms. 
Otherwise the config can be stored in the default place, i.e. ~/.lazarus 
on Linux.

2) Snapshot installation
------------------------
IMO snapshots should always install into user-land, because they are 
subject to updates/overwrites. I.e. we have a writeable Lazarus 
directory for storing the config.

3) SVN installation
-------------------
The checkout must be bootstrapped, with meaningful FPC settings. Here I 
like the Windows snapshots, that come with their own FPC, so that 
everything can be setup from and in the new Lazarus directory (used for 
Make).



In all these cases [1..3] we'll have to consider what will happen on a 
second install. Here I see a need to *split* the configuration, into 
general and version specific items:

A) FPC source and binaries
--------------------------
The last used version may be reusable, but after dramatic changes the 
user has to choose the FPC version to use. Error messages should be 
sufficient to let the user know when to switch to a different FPC version.

B) Other binaries (Make...)
---------------------------
These should always be reusable, subject to a default config.

C) Lazarus source and binaries
------------------------------
These are always private to an installation, and consequently cannot 
reside in the default config.

D) IDE history
--------------
Filenames, projects and packages contain path information, so that these 
are incompatible across multiple installations. No such information must 
reside in the default config.

E) User settings and additional (non-standard) packages
-------------------------------------------------------
These also can be stored in a default config, provided that the config 
format is compatible across Lazarus versions!


These different requirements suggest to me a config separation into:
- machine specific (default FPC config?)
- user specific (default config)
- version specific (config in every single Lazarus directory)
- project specific (stored together with every project)


Conclusion:
A single config directory doesn't make sense!
Some settings have to go into a common (default) config,
others have to go into a version specific config,
and project configs can override some of these settings.

DoDi