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

Martin lazarus at mfriebe.de
Sat Jun 8 11:35:40 CEST 2013


On 08/06/2013 09:49, Michael Van Canneyt wrote:
> On Sat, 8 Jun 2013, Mattias Gaertner wrote:
>> Well, that would be a very flexible solution.
>> But that is only useful for power users. All others would suffer. So,
>> maybe we have to provide a normal and an expert view.
>> Same for the custom options: Some need a simple memo, others need
>> a matrix.
>
> If I may chip in, defending the normal users:
>
> I can see why you're making this new page.
>
> But this new page only makes sense when you use different build modes:
> For build modes, I think it is an elegant solution that lets you see 
> in one glance, what options are used in the various modes.
>
> But build modes I consider something that only experts or powerusers 
> will use, those who do many builds for different targets/platforms.
>
> The normal, casual user does not need this.
>
> The additional specification of 'where the option is stored' is 
> powerful, but adds yet another layer of complexity, another source of 
> misunderstandings, and necessitates almost a dialog 'where did this or 
> that option come from'.
> The additional option of 'to what to apply an option': same thing.
>
> However, for the casual user, this is complete overkill.
...

In the light of this, maybe a few ideas.

The new grid is indeed an advantaged page. A concept that already exists 
for the editor-mouse-setings. A page normally hidden, by a page offering 
a few pre-defined defaults.

1) Maybe the entire grid, should be in the build-mode dialod (the 
dial[og that pops up on top of the options, if the [...] next to the 
dropdown is pressed). That dialog would then need several pages too.
Yes, I know, it highlights the "current b.m." and therefore makes use of 
the drop down. But that is not important....
On the other hand, if a simplified (see 3) page exists, then this could 
be nested as a sub-page)

2) It will become a bit (a tiny bit) more clear, if there are 
pre-defined build mode (debug/release). But that is a drop in the ocean.

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
- modify out-dir for all packages (maybe this should be automated, using 
the build mode name, or some unique id derived from it)

Not sure, maybe, instead of "all packages" the user can select.

like the mouse-opts, this would create the correct advanced settings. 
(Though in the xml, it is stored as the 2pre defined setting)

One thing this can do, is it can force setting on packages. This can not 
be (easily) done with the other options.


--------------------
On that matter, I am not sure, if the IDE-macro page should be advanced too.




More information about the Lazarus mailing list