[Lazarus] Lazarus config woes
DrDiettrich1 at aol.com
Sat Apr 2 18:22:01 CEST 2011
>> When multiple directories are in a search path, the search stops on
>> the first item (file...) found. That's common practice, isn't it?
> I explained below, but I do again.
> In order for that to work, WITHOUT the user needing to be aware of doing
> anything. EVERY lazarus must come by default with local config.
No. When the global config is in the search path as well, as should be,
and is without -pcp, then the global config is found.
It smells like you search for an excuse for the weird decision, that
(currently) the *global* config path is overwritten by -pcp. The global
location can be used (be in the searchpath) implicitly, as the last
resort, no need to ever specify it explicitly.
> Then local config will ALWAYS be found, which is the same as having NO
> If Lazarus comes without a local conf by default, then we are back to
> where we are now => a global copy will be created, and used
A global config is be created only when none exists. Otherwise that
global config is used *and* updated, by default. The unaware user may
wonder afterwards, why his other Lazarus install will fail or behave
unpredictable, due to the changes in the global config :-(
Specifiying an (non yet existing) -pcp creates a config in that place,
but its unclear from where the settings are read.
> *** There is one option though, since we have the setup dialog => it
> could ask the user where (e.g. exe dir) to create the config.
> BUT that is at best a partial solution.
> Because, if a user installs a 2nd lazarus, it may not (yet) have a
> problem with the global config. However the use may then change it, and
> the glabal config gets updated. The global conf now is incompatible with
> the 1st/original installation. That is almost never what the user wants.
> the user wanted a new config for the 2nd installation. (but now the 1st
> install will ask about creating a new one).
> Since the 2nd installation (if the config is compatible at the time of
> first startup) has no way of knowing there is another install, it just
> requires the user to tell it.
Exactly what I mentioned above.
As long as the Lazarus directory is stored in the config, the IDE can
compare it with the current/given directory. When both differ, a new
config can be created automatically, in the actual Lazarus dir. At least
the user should be informed of such an obvious mismatch, and be asked
for specification/confirmation of the directory to use (create/overwrite).
In the simple case, when the next IDE invocation with the same arguments
finds the same Lazarus directory mismatch, it also will find the
previously created config in the Lazarus directory, and can use it
automatically - no need for any further updates.
But when its required to specify the new config explicitly as -pcp, then
a new script or desktop shortcut will have to be created, or an existing
one has to be updated accordingly. This should be told and left to the
user, because IMO any automatic updates may fail for various reasons.
>>> 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
> the explicit pcp dir makes no difference to anything that I said below
It does, even if you may not have noticed yet (see above).
>>> => 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)
> Well that leaves the question why almost every software has moved from
> exe config to global config?
For several reasons:
1) Apps usually are stored in directories, which are not writeable by
This is okay to prevent the user from garbling his system, but is
inapplicable when the user is allowed, and may be forced, to rebuild the
IDE. That's why a Lazarus EXE *never* should be stored in a place, that
is not writeable by the user.
2) In multi-user environments, typically managed by an administrator,
all users shall share common binaries, while every user shall be free to
use his own preferred settings.
3) After  it turned out that most apps will deserve machine specific
(protected) settings, in addition to user-editable settings. That's why
most configs are organized in a hierarchical manner, not only in a
simple global/local fashion.
This is the situation where I vote for a separation of the Lazarus
config, into an installation specific part (mostly the pathes to
external tools), and into user preferences, which are applicable to
multiple installations (versions) of an application.
4) Apart from all that, it still makes sense to have all-in-one
distribution kits, for e.g. evaluation purposes, that can be installed
and removed without affecting the machine permanently, and do not
require administrator privileges for that purpose. Recent examples are
plug-in distributions, on chip cards or USB sticks.
> Config in the user dir has many advantages. Various backup solutions
> will take care of it, user profiles that can be used accross many
When backup solutions have to take explicit care of such things, this is
*not* an advantage.
Current Lazarus configs are *not* shareable, neither across multiple
local installs, nor across workstations. This argument deserves a
redesign of the config storage, with a separation into
installation-specific and -independent settings.
>> 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. ;-)
> Well that's a new topic. If a profile manager was created, it could have
> the functionality of creating desktop shortcuts (including fro linux)
> Though personally, on linux I never use the desktop, I always use a
> shell. And I have my own startup scripts for most apps that I use
Vive la différence :-)
I've often been thinking about writing my own installation manager, but
finally I was happy whenever I could make a new installation work,
without going into implementation details.
What nerved me specifically was the inability to have multiple user
accounts for isolated Lazarus installations. If this had been working on
Windows, I had been happy with dedicated users for e.g. standard release
versions, and other(s) for current development (SVN/Git based).
>> 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 :-(
> But the config is currently shared? That was the whole point of this
I think that you pointed out yourself, above, that effectively no two
Lazarus installations can share the same config.
But perhaps I overlooked something, so a last question: where can I find
the documentation of the Lazarus commandline options, mentioned allover
> With local/exe-dir configs, that problem remains/becomes bigger.
> Otherwhise this is a change of topic: Keeping the config directory as it
> is, but make sure the data in the config will not conflict between
Right, we can close this thread, after all arguments have been exchanged.
More information about the Lazarus