[fpc-devel] Threading support and C library under Linux/Unix

[Hans-Peter Diettrich]

Marco van de Voort schrieb:

>> The Kylix-like addition of an C compiler would help to solve such 
>> issues, that arise from the use of *any* C code with FPC.
> 
> Well, since this is about a maintenance problem, it would only solve
> it if the maintenance of the C compiler would be lower than the
> maintenance of fixing the headers/RTL.....    Which I doubt strongly,
> even if we forget about the gigantic initial costs (making a
> production C compiler)

The C compiler IMO won't cost much, since it can use the OPL code
generation. ToPas can produce an FPC compatible AST for that purpose. It
also is already configurable, to emulate almost any existing C compiler.
I've tested with CBuilder, MSVC and gcc, and their header files, so that
such existing header files can be used instead of e.g. the MinGW or
Cygwin rewrites.

I'm just about to make the FPC compiler usable as a mere syntax parser,
with all semantic actions, like code generation, moved into
(exchangable) units. The C front-end could create the tree(s) for
immediate use by these semantic procedures. Since the separation of the
semantic code is already sponsored by Adem, I will do it anyways without
burdening the FPC team. The result only depends on the goodwill of the
FPC developers, to accept that separation and put it into the FPC trunk,
so that the future development can be done without syncing different
codebases. I'll start an according thread as soon as I have some more
concrete ideas and results.


> If a real systematic problem here would ever appear, I would go more
> in the direction of a configure like hack. Characterising the system
> by compiling small C programs.

I don't like that hack, and have ideas also for this problem. IMO a
header file with the description of the capabilities of a concrete
platform will be sufficient, with low maintenance requirements.
Something like the autobloat tools try to achieve, but with a better
implementation. Here the outstanding FPC handling of platform specific
differences will be very helpful.

<rant>
The major problem of the open source (GNU/Linux...) world is the lack of
cooperation between the maintainers of the various platforms - they
always ask for perfect implementations which they can use off-the-shelf,
but are not willing to spend a few hours even in the specification,
adaptation or configuration of a new model. Since we already have a team
of platform maintainers in the FPC project, it should be much easier to
specify and implement a model for handling the platform differences. In
the best case we could end up in an simplified and improved autobloat
replacement, which all the C experts could not provide in past decades.

Perhaps in a few years nobody will remember gcc and autobloat any more,
because then everybody uses our superior fcc ;-)
</rant>


> I think I don't entirely understand what problem this paragraph is
> about. Yes, we have two errnos now, but not doing that means that you
> essentially have to create a configure like layer. (since this is not
> even automagical for C programs)

My idea is an abstraction at the header-file level, eliminating the need 
for an adaptation layer in code. It's not a very concrete project right 
now, since I could not yet identify all the possible problems.

> In the light of that, I have no problem with the current solution.

I have no problem with the existing solution, too, but together we 
possibly could find easier and more consistent solutions for all these 
problems.


Okay, it's time to wake up and stop dreaming, there remains enough 
higher priority work for everybody right now...

DoDi