[fpc-devel] The future of fpmake

[Darius Blaszyk]

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.


>>> 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. 

>> 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.  

>> So why not use it also for other projects? Ok, perhaps the cdash functionality belongs in a different tool (although it could be in fpmake), but let's not limit fpmake only to FPC please. Let us (end users) also play with it ;)
> 
> You're of course free to do as you please. But when judging your proposals, I will always reason from the point of view of a FPC-only build tool. You're welcome to view it broader, but this is not the intended purpose of fpmake.
> 
> The idea is to keep it simple to build and FPC code. As long as your proposals do not conflict with that: feel free. Till now you're doing a good job :-)

I'm all for that. Let's live peacefully together :)

-D-