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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
