[Lazarus] Using different FPC versions

[Mattias Gaertner]

> Michael Van Canneyt <michael at freepascal.org> hat am 10. Februar 2014 um 14:38
> geschrieben:
> 
> 
> 
> 
> On Mon, 10 Feb 2014, Mattias Gaertner wrote:
> 
> > On Mon, 10 Feb 2014 11:57:08 +0100 (CET)
> > Michael Van Canneyt <michael at freepascal.org> wrote:
> >
> >> [...]
> >> I never (actively) use IDE macros. Probably they get used in the
> >> background.
> >> [...]
> >> Ah, in this completely un-understandable dialog. I am avoiding it like the
> >> plague :(
> >>
> >> A GUI is meant to make things simpler, not complicate them, this dialog is
> >> IMHO a
> >> prime example of a violation of that principle. (somewhat like the MS
> >> Access visual query builder)
> >
> > I don't know the MS Access visual query builder.
> 
> I meant it just as an example where the visual layer is actually worse than
> the original text-based interface: it is easier to type SQL than use the
> visual
> dialog in MS-access.

I see.
A text based edit with the pascal like syntax of the conditionals was
considered, but selection of build modes and storage would be awkward and it
would be too flexible - you would need a debugger. Also upgrading would be much
harder.


> > You want different settings for different compiler versions.
> > The current GUI allows this with a few clicks and a macro.
> 
> If you understand it, yes...

A grid is powerful and not intuitive. I agree.


> > You dislike/avoid build modes, sessions, macros and custom packages,
> > so you dislike 90% of this page. I wonder if it is the GUI you dislike
> > or the features you don't need.
> 
> Hm. Let's analyse this paragraph:
> 1. Build modes are IMHO indeed a misguided concept.
> 2. I didn't say I dislike macros ? I simply don't use them in the IDE.

That's why I wrote dislike/avoid. I does not matter why you don't use them. My
point is that if you don't use them, then you (obviously) don't need a GUI for
it. It's like you want to change a value in a database and someone gives you
phpmyadmin. That's a bad GUI for changing one value.

> 3. "custom packages", I simply don't know what you mean by that.

Packages that require special settings. For example if you want to compile all
packages with -O2, but one package crashes with that, you have to define an
exception.

> 4. Not sure what you mean by 'sessions' either ?

When several people work on a project, you need your own settings, that are not
stored in svn/git/whatever. These settings are stored in the "session".


> So you got at least 1/4 statements correct :)
> 
> That said: It really is the GUI that presents me with problems:
> 
> I find makefiles with all the variables, rules and whatnot far easier to
> understand than this dialog.

A Makefile is more like the whole lazbuild.
You have to read several documentations to understand a Makefile. You need to
know the Makefile syntax, variables, shell syntax, environment, tools options,
etc.
BTW, 'make' supports build modes too.
But even after years with Makefiles I still have trouble understanding them, so
I doubt that Makefiles are "far easier".


> (just like I find it easier to type SQL than use the visual query builder in
> MS-Access)

IMO the SQL comparison does not fit in this case. SQL has far more possibilties
than the "Additions and Overrides". The data could be stored in SQL in only 1..3
tables.


> Unfortunately, it is difficult to mix makefiles with the lazarus packages.
> (that is just meant as a constatation, not meant as critique)

You can call 'make' instead of the compiler. And you can pass options. The
problem is the missing way back from the Makefile to the IDE. The IDE needs the
options for parsing the sources.


> >> Since the presence of different compiler versions is a given for the
> >> lazarus ecosystem,
> >> you might consider changing the defaults to what you propose in the
> >> example.
> >
> > Many users do not switch often between different compiler versions.
> 
> I would think all Lazarus/FPC team members, as well as component creators
> are in this situation. I may be wrong, of course.

That's an important group.
But I do hope that Lazarus is used by more people than this small group. ;)


> > Some packages do not support overriding the output directory.
> 
> Huh ? These packages are not very well designed then.
> A package should always be oblivious to the output dir.

Examples:
-closed source packages
-packages compiled via script or Makefile (user has to adapt the script, which
might be difficult).


> If it is not, it should IMHO be discarded from the lazarus installation.

All packages of the Lazarus installation can be compiled to other directories.
That's needed because they could be installed read only.


>[...]
> > Others have asked to add the buildmode by default.
> 
> Hm. I don't even understand this sentence :-(

Sorry. Theoretically: When we ask "how should the output directory override look
like in order to reduce compilation", you will add FPVVer macro, others will add
the buildmode macro, and other will want to add some environment variables.


> > I guess this should be kept optional.
> >
> > Of course we can add menu items for frequently asked overrides.
> >
> > Another possibility is to add a wizard to quickly setup some common
> > options. Similar to the initial setup dialog.
> 
> In view of the "Some packages do not support overriding the output directory."
> you mentioned earlier, I somehow doubt this is a workable idea ?

If someone uses such a package, he can choose 'no override'. That's what I meant
with 'keep it optional'.


> But hey, never mind, my mail was not meant as a complaint.

If that was not a complaint, then what is?

Mattias