Show quoted text 7 lines
> 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.
Show quoted text 5 lines
Then local config will ALWAYS be found, which is the same as having NO
GLOBAL
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.
Show quoted text 14 lines
*** 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.
Show quoted text 12 lines
>> 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).
Show quoted text 9 lines
>> => 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.
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 the user.
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 [2] 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
workstations.....
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.
Show quoted text 9 lines
> 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).
Show quoted text 7 lines
> 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
discussion.
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 this thread?
Show quoted text 5 lines
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
installations
Right, we can close this thread, after all arguments have been exchanged.
DoDi
