[fpc-devel] The future of fpmake

[Jonas Maebe]

On 31 Mar 2011, at 14:42, Marco van de Voort wrote:

> In our previous episode, Jonas Maebe said:
>
>> I still prefer those Makefile.fpc files very much to the fpmake.pp
>> files. The fact that fpmake.pp files are plain Pascal code makes them
>> extremely flexible, but at the same time that also makes it much
>> harder to quickly get an overview of what they do.
>
> Well, I can be quite short about this: me too.

That's good news :)

> However I consider this a transitional problem only.  We are still  
> in the
> raw plumbing and discovery phase.  In time, I assume some  
> autogeneration
> helper functionality will emerge to make it at least (way) more  
> bearable.

That's all I'm asking for. However, auto-generation will exclude  
directly modifying fpmake.pp (just like you currently can't safely  
directly edit the Makefiles). The structured format can of course have  
provisions for injecting Pascal code into the generated fpmake (just  
like you can insert plain Makefile code via Makefile.fpc), but then at  
least the parts that are auto-generated and those that are not are  
strictly separated and cannot be accidently overwritten during an  
update. Or, in other words: you don't have to spend time on looking  
for custom code before updating the build instructions.

> OTOH the trouble should not be exaggerated. I did the entire packages/
> hierarchy in a few hrs spread over 2 days, and that was without any
> previous fpmake experience at all, and communicating with Joost.

There's still a difference between initial conversions and maintenance  
afterwards. The first time there are no potential older changes you  
might accidentally overwrite.

> New packages are not added that often,

At least the package I referred to (univint) tends to change  
significantly over time. The Mac OS X 10.6 SDK split a bunch of  
headers and removed others compared to previous versions (most C  
programmers use umbrella headers, so they don't notice that either).  
As Carbon gets phased out, more and more things will probably change.  
It's not really feasible to manually go through the current list of  
dependencies and to update them where necessary. Otoh, replacing them  
with a newly auto-generated list currently risks removing code that  
someone else added to manually to fix something.

> The trouble is that makefile.fpc does not contain all information.  
> It is not
> a closed system, and has barely enough info to build, and depends on  
> the
> autobuilding capacity of the compiler. Something that can't be used  
> for
> packaging and other features.

That's why I mentioned "or any other structured format".

> IIRC there were two solutions. I first did parts with own based small
> filter programs that parsed -vt output. Later Joost pointed me to some
> script that was slightly better. For the rest I had a bunch of  
> templates
> ready.
>
> The raw output was then checked and amended for OS and CPU specific  
> cases.
> It was very semi automatic, but the simple packages (one OS, or no  
> OS/CPU
> specific data) went fairly fast, and the bulk of the work was
> customization of the template.
>
> I can't exactly remember if this also handled the include situation.  
> Afaik
> first the units were done, and later includefiles were added.


Unless it's fully automatic so that the current set of dependencies  
can just be replaced with a new set of generated ones, that's not  
really doable for univint, I think.


Jonas