[fpc-devel] The future of fpmake

[Michael Van Canneyt]

On Thu, 31 Mar 2011, Darius Blaszyk wrote:

>
> On Mar 30, 2011, at 11:46 PM, Michael Van Canneyt wrote:
>>>>>>>> fpmake build debug
>>>>
>>>> I would prefer a named option, i.e.
>>>>
>>>> fpmake build --profile=debug
>>> from the users perspective this is not very friendly.
>>
>> It is more clear what is meant. All other options are also specified with a --option
>
> I won't make a fuss about this as it's also a matter of taste. More important is the functionality itself.

Exactly :-)

>
>
>>>> and I think TDefaults.Profile needs to be a) A collection.
>>>> b) Loadable from some config file, I suppose ?
>>>> --profile then just selects one item in the collection.
>>> So you mean have a fpmake.pp and next to that a fpmake.cfg?
>>
>> Not next to it, on a central location on your system.
>>
>> Rationale:
>> I imagine that one wants to have some often-used profiles on a central location.
>> These will be machine specific:
>>
>> debug
>> profiling
>> testing
>>
>> if you download a package and compile it, you'd have to edit the fpmake.pp
>> and add these profiles each time.  If the profiles are in a ~/.fpmake
>> file, which is loaded on start, then you need to define the profiles only once, and they will be available for all packages you wish to compile.

> One remark, with your reasoning, all packages will support each defined
> profile.  This is not necessarily the case, also for FPC.  You could even
> argue quite the opposite, but as long as you have comprehensive messaging
> it should not be a problem, although it will generate quite some "false"
> errors on building.

I think it highly depends on what you will put in the profile.

Standard profiles such as debug and release profiles will probably 
simply have some -gl -vw -dDebug or -Ur and -O2 options, which are 
understood by all projects.

if your projects profiles need more specific defines or options, 
then they must obviously be code in code.

>
>>> That does not make sense. The fpmake.pp in itself is a config file (well sort of). I would just prefer to keep it simple, maybe have the user register the profiles in fpmake.pp?
>>
>> See above for the rationale. But obviously, they must be definable in code as well.
>> I see the above as an add-on to manual definition only.
>>
> As long as it's possible to register profiles in a fpmake file itself, I'm
> fine.  For a standalone project this makes more sense.  Imagine you have
> debug, profiling and testing setup locally but the project adds
> "profiling" as a build profile.  Then fpmake would not recognize it (and
> raise some sort of error message because it's an invalid profile) until
> you added it yourself to the local config.  So having both options is best
> here.

Agreed.

I would definitely load profiles from file only after all user profiles
are made, and would not load something again that the user already defined in code.

Like I said: an add-on to manual definition only...

Michael.