[lazarus] Clean build from nothing

[cryst]

I hate outlook. After spending 1/2 an hour replying, it crashed before
sending the message...

All in all the gist of what I was saying is that I can understand your
reasoning and although I was surprised to find you didn't use the libraries,
I can see now why you didn't.

Chris

----- Original Message -----
From: "Marco van de Voort" <marcov at stack.nl>
To: <lazarus at miraclec.com>
Sent: Wednesday, June 25, 2003 6:00 AM
Subject: Re: [lazarus] Clean build from nothing


> > > 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.
>
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>    archives at http://www.lazarus.freepascal.org/mailarchives