[Lazarus] New compiler options page "Additions and Overrides"

[Martin]

On 08/06/2013 13:59, Mattias Gaertner wrote:
> On Sat, 08 Jun 2013 12:13:58 +0100
> Martin <lazarus at mfriebe.de> wrote:
>>> Michael's point was that casual/normal users do not want build modes at
>>> all.
>> I think differently:
>>
>> A majority of users want an easy to use debug/release build mode.
> I doubt that. I know more people not needing build modes. They
> ship/install there programs as they have tested them.

Ok, we are getting off topic here. But to follow your lead:
What do they do, if there app fails in test? Eventually I would expect 
they need some form of debugln (either with writeln/debugln or in a 
debugger)
Such debugging needs an exe, that has debug info, or that has writeln or 
other logging.

I will agree people who have not even an idea, that something like a 
build mode exists, will of course do all those changes by hand each and 
every time. But that does not mean they would not benefit from build 
modes. If they would however benefit from it, and once they learn that 
such a help exists, then I do not see, why they should not want it.

I do agree, that as long as they do not have an idea that something 
exists, or even only could exist, then they may not desire it either.

Or do you mean they ship their release with all the debug info in it?

-----------------------
To get back closer to the topic:
never mind the exact percentages, or if the amount of people is 
sufficient to be called a majority... and never mind how or if to count 
people who do not want it yet, because they do not know it could even 
exist....

Do you think, it is agreeable that release and debug build mode are 
desirable, even for people who are not otherwise want/need to dig into 
the functionality of the new matrix (and may or may not have the 
knowledge/experience/skill to do so)?

Would it be beneficial to users to be able to have debug/release, 
without having to learn the entire new matrix stuff?

>>>> 3) Having pre defined buildmodes, there could be a simplified page, with
>>>> common options (like the mouse opts). Those would probably all be stored
>>>> in the lpi (the place I guess beginners would expect it, as all the
>>>> other options go there too). So there could be things (all acting o the
>>>> currunt B.M>, as do all other chek-boxes)) like:
>>>> - add/strip debug to/from ALL packages
>>>> - set optimization (0..3) to all packages
>>>> - define ( -dSYMBOL) for all packages
>>>> - set option for all packages
>>> If you mean adding all the compiler options pages in the
>>> environment options: -1
>> No I did not mean that.
>>
>> I meant adding a simplified page in the project options, that allows to
>> control a subset of the new functionality (very much like the mouse is a
>> subset of the advanced mouse)
> I see a difference here. The normal mouse options has a few
> controls and can do a few things.
Please go, and count again: 48 dropdowns, each more than 10 entries....

> The advanced mouse options have
> lots of tables and you can fine tune a lot of settings.
> OTOH the new 'Additions and Overrides' has a few cells with custom
> options, IDE macros and output directories. You want to add page(s) with
> many controls that can do less.
Essentially less. Though more correct would be "with more controls, that 
can do less"

The complexity of a page is not only defined by the number of controls.
In the grid, the complexity, is due to the amount of things you can do, 
with very few controls.

Having controls that a dedicated to a single function instead will 
simplify things. But since the amount of things that can be done is too 
big to have a control for each of those things, it is needed to pick 
some of them only.

So I still thing that the average user would benefit from a subset, of 
options. (If we miss one that turns out to be requested a lot, it can be 
added later)

>> "optimization level" most likely too.
> Some packages fail with some optimizations. For example we have
> currently a few workarounds in the LCL to work with some optimizations.
usually due to compiler bugs.
Users can get the same issue in there own code, yet we allow them to 
change the opt level. And we also allow them to edit it in the package 
opts...



>> "removal of -Criot / run time checks" (NOTE removal, NOT adding) should
>> be save in most cases (to be honest, a package that requires it to be
>> set would at least be suspicious... That is, it can probably be
>> constructed, but as for real live...)
> Do you want one checkbox to add -Cr- -Ci- -Co- -Ct-?
> What about the other checks?
>
>
riot was only an example selection / should apply to all such checking...

I did not say a single checkbox. Though a single checkbox would be 
possible (for remove).
The point is, that if you have packages (including self made ones) that 
have those options enabled. then it may be helpful to remove those 
options for a release build...

It is possible to do that in the matrix. But the less experienced user 
would not be able to do that.

--------------------------------------

Conclusion:

IMHO the gap is too big. There is only

- use the matrix, but that requires high level of experience  from the user
- do not use it

But not using it excludes you from all of it....

There is no middle option for the user that is trying to advance, but 
not yet that high up.