[fpc-devel] The future of fpmake

[Michael Van Canneyt]

On Wed, 30 Mar 2011, Darius Blaszyk wrote:

>
> On Mar 30, 2011, at 9:29 PM, Michael Van Canneyt wrote:
>>>>>>> - managing debug/release builds (also cross-compiling)
>>>>>>
>>>>>> What is failing in the current system for this ?
>>>>>
>>>>> I was thinking to be able to do something like :
>>>>>
>>>>>> fpmake build debug
>>>>>
>>>>> This will add some debug options to the build process. Also it should be possible to create a custom build profile.
>>>>
>>>> And how would you do this ?
>>>>
>>>> I don't want to complicate fpmake unnecessarily.
>>>
>>> Improve the command line paring algorithm. It should check if there is something behind the build command line option. If so then it is a named build profile. In fpmake you could check the TDefaults.Profile property to determine which options to add.
>>
>> 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

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

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

>
>> Other than that, I think this is OK.
>>
>>>
>>>>
>>>>>>> - cmake like system (display and store information on builds and test suites, etc)
>>>>>>
>>>>>> fppkg should handle that part of the job, not fpmake.
>>>>> To make fppkg work for my own project I need to add a fppkg.cfg to my project right?
>>>>
>>>> There is no such thing as 'fppkg for a project', so I'm not sure what you mean here.
>>> But I am talking about using fpmake for projects other than FPC. So the cdash (not cmake as I mistakenly wrote in the mail) idea should also work for standalone projects.
>>
>> In that case, I don't understand what you mean.
>>
>> fpmake's intended use is to compile your FPC code. I can see the use of trying to run a testsuite, build docs and a binary zip for distribution: they are all FPC related things.
>>
>> But it is not intended as a general build system (i.e. replace make or ant or rpm or deb).
> What do you mean with "general". Fpmake is a build system right?

fpmake is intended as a build system for pascal code.

> 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 :-)

Michael.