[lazarus] Clean build from nothing

[Marco van de Voort]

> > Ok, and true. Most of the changes will be very internal. Most bugfixes
> > in the 1.0.x branch usually are.
> >
> > > I am shocked that FPC doesn't use libc at all.
> >
> > That's normal. The usual documentation sketches a quite rosy picture, and
> > most people react that way. There are good reasons though, see below for
> > a selection.  Most people consider them reasonably
> 
> I was shocked because there is so much code available for use, it seems like 
> re-inventing the wheel.

That mantra is overrated. Like in the real world, reuse is often many times
more expensive than writing your own. Not to mention that the analogue would
be to slap a wheel from a bus under your Ferrari.

I tried to give you some of the reasons. 
 
> > > More then that FPC doesn't use any C code to build itself.
> >
> > Why would it need it? C is not "special" in anyway. Pascal is better even.
> 
> C is special in that it is pervasive.

Sure, but that doesn't bring anything as soon as you only use it
as vehicle to build another language. Except the headers, but they are
already discussed thoroughly

>  I agree that pascal is a better language, so let's not fight about that.

I don't really hate C.
 
> > > Why avoid all that good code?
> >
> > Are you so sure it actually _is_ good code? :-) And more important, from
> > the perspective of somebody not really interested in C?
> 
> The code has been worked on for more then 3 decades...

Unix might, but not anything *nix related.

No. gcc and libc (the first tools from the GNU stable) date mid-late
eighties. FPC early nineties, and used Turbo Pascal to bootstrap (maybe 1.0
might still be able to do that), which is older, and more stable than gcc by
far at that time, and available on dos.

And remember that pre 1992-1994 internet access was quite different. Harder
to get, no web etc.

If there are old Unix sources in Linux, that won't take long anymore, with
that SCO lawsuit (admitted, there will be some early BSD code from say mid
eighties in it)

> > The main reasons for not doing a gcc port:
> 
> <big snip>
> 
> That was a lot of typing to argue against doing a gcc port. (which was not
> at all what I had in mind). I was thinking more of building the fpc
> compiler using tools like flex and bison etc to handle the parsing, 

Pascal is basically a LL(1) language, and FPC is a variation on that, and
use the for Wirth traditional top down parsers, usually handcrafted. Flex
and bison are targeted to generate LALR bottop up parsers.

> making a mini compiler which could be used to make the main fpc. 

What would be the advantage of that? The compiler is a 700k static binary
already. Also keep in mind that the compiler uses OOP, so that the subset
of the minicompiler would be fairly large.

> at all considering making gcc and fpc one in the same.
> 
> > - _Bootstrapping_ and crosscompiling issues are much easier than most
> >   outsiders expect. Often even easier due to smaller dependancies (both
> >   libraries and tools used in the build). You saw yourself, essentially you
> >   need as,ld ,make and a start compiler to build the entire tree. And some
> >   platforms even eliminate AS.
> 
> I have yet to experience this :)

We have one compiler per architecture. Crosscompiling for other OSes only
needs cross-binutils, the appopriate FPC rtl and libraries, if you need
them. Nothing more.
 
For *BSD <-> other *BSD <-> linux crosscompiling I don't even do that for
"small" programs (this includes the 6 MB source compiler).

Compile on Linux with the BSD rtl, copy to freebsd, brandelf, ready. With
normal binutils.

Crosscompiling for a different processor needs a real crosscompiler and
a RTL and binutils for the target. However, this crosscompiler is 
again only a 700kb static binary.

Moreover the binary fpc can hide it, so as say FPC has 5 architectures, there
are 5 binaries (e.g. ppc386, ppcppc, ppc68k, ppcsparc ppcalpha) that compile
for the give architecture. One (the native one) is normal, the rest is cross.

fpc -Palpha <the rest of the parameters will make "fpc" call the corresponding
binary (ppcalpha) and give the parameters.

> > There are also disadvantages:

> > - inability to interface to headers of the other gcc languages natively,
> >   most notably C, C++ and Objective C. (the last one because a major Mac
> >   OS X api is based on it)
> 
> I wouldn't consider that a disadvantage, it's simply a way of extending
> fpc's reach. (or am I misunderstanding you).

Header conversion is pain. As said before, it could be much less painful if
there were something else, more abstract set header other then C headers to
start with. The reasons for that are the macro tricks etc.

This is even a problem under C. Configure exists because of it, just to
compile small programs and pry the result apart, in order to get info from
the headers, as one can't do it automatically. If you include the headers
they are preprocessed and loose a lot of info.
 
> >   derivates or C like languages Most unices fail to have a master set of
> >   headers in a abstract, easy parsable format from which other headers
> > could be easily generated.  Even Windows does this a bit by providing a
> > version of its newer modules in IDL.
> >
> > This might change in near-middle the future (by setting a define when
> > recompiling FPC) to switch the default to use libc as back end on *nix.
> 
> I've got to be misunderstanding something. If you are able to do a
> syscall, why can't you do a lib call?

In assembler you can do everything. Nowadays we can also make lib calls.
(the problems were alignment, calling conventions etc)

The library interface is simply more in a state of flux than the kernel.

Also with the library usually you have to take the whole package. (like e.g.
threading in a way compatible with libc) While with the kernel you can take
primitives and build your own system on top of it.

> Isn't it a case of translating a C header into a pascal header and linking
> it in? (I think there's code out there somewhere to handle this).

Hardly. The tools only work with reasonably clean headers, and usually are
written to process a specific (clean) set of headers. Sometimes they generate
unreadable output.

The *nix OS  headers simply use a too large subset of both the language and
preprocessor to adequately convert them automatically. (as in e.g. a kind of
configure step) The same for most of the packages, though some are
reasonably clean, but all different.

The win32 headers are much better in that respect. I hope the Linux
standarisation together with the diminishing amount of Unices in active
development will improve this somewhat.

I hear QT has a scheme with a perl script that generates headers from an
abstract representation. I really hope that caches on (except the use of
Perl:-)

The main problem is that each team writes its own headers with its own
style. The language it too complex to process fully automatical and get
decent output. It is a bit like decompiling. Possible under certain
conditions, but you won't like what you get.

> > The fact that library and OS teams don't have any abstract (so non C)
> > headers that can be easy auto-ocnverted makes this unnecessary painful.
> > However that is not our choice, but the relevant teams.
> 
> I think the C version is an abstract version. Just not the abstract you would 
> prefer :) 

No, I wouldn't call C .h an abstract header, at least not done as under
*nix. It describes the C data structures that map to the structure they want
to have. It doesn't the describe the structure itself.

- You can't derive e.g. usage of a SET (which is an abstact structure) from
  the header.
- Which param is IN/OUT/INOUT  from .c/.h? 
- Strings and their bounds.  What is the upperbound of the pchar? 
- Under FPC we have OOP. We can't use these features if the base representation
  doesn't grasp the concepts.

> > The fact that C and C++  are such horrible languages to implement also
> > prohibits the possibility to make a simple C subset compiler part of FPC,
> > just to get at the headers.
> 
> Well OpenGL, SDL sound libraries are some of the libraries that immediatly
> spring to mind. Although I know that Jedi-sdl is in fact a pascal library
> to do those three things.

There are FPC specific versions of both libraries. OpenGL even comes with
FPC.
 
> > I hope I showed you a bit of what is behind the commonly presented
> > idealistic view of Linux and Unix in general.
> 
> Well I must confess that I commonly use the tool-chain for C C++, Java,
> python and perl. I just assumed that it would work for Pascal as well.

Bad guess :-)
 
> > If you have more questions related to this, I'd be happy to answer them.
> 
> No I think I've had enough education in this area for now.  :) My background 
> is Windows (C/C++/Delphi/turbo pascal v2 on) and Linux (C/C++,python). 

I've been using BSD (later FreeBSD) on the university (and later at home)
for a decade now, half of which working with Pascal, and half of which with
Modula2, another Wirthian language.

I used both languages under Dos (and a bit Windows) too.