[lazarus] Clean build from nothing

[cryst at golden.net]

On Tuesday 24 June 2003 06:23 pm, Marco van de Voort wrote:
> > My education continues....
>
> And you need it ;-)

Don't be nasty, self depreciating humor does not need sarcasm 8P

>
> > I thought for sure that I saw some C files.  OK so I need FPC installed
> > before I install FPC. I understand that now. I'll start again from
> > scratch tonight and make notes of what I do. (and were I had to
> > backtrack). I'm going to try for fpc 1.0.8 from the CVS since it is so
> > near release any differences between what I get and what the release is
> > should presumably be small.
>
> 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.

>
> > 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.  I agree that pascal is a better 
language, so let's not fight about that.

> > Is this by design?
>
> Of course it is. 50-100 MB source don't fall out of thin air. The project
> has been running for a decade.
>
> > 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...

>
> 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, and making a mini 
compiler which could be used to make the main fpc. I wasn't 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 :)


> There are also disadvantages:
> - the "good" code in gcc that simply isn't worth the trouble, but still has
>   to be reimplemented: codegenerators for a lot of processors, optimizers.
> - 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).

> ----------
> The libc issue
>
> The libc thing is a bit different. I still think choosing syscalls was a
> good choice at the time because
>
> - libc activity instability and libc->glibc transition.
> - different versions on a lot of distro's
> - again buildprocess complications.
> - programs that don't use libraries are only slightly larger, and
> - It's not just libc, but also libm, libgcc etc. However this is a trend
>   that might be a reason to do it in the end.
> - Headers have to be translated and  kept up to date. The few functions we
>   use from libc in some cases are much easier to maintain. Binary
> interfaces like the kernel rarely change.
> - other unices use other libc's. That means a header translation per OS,
> not one for all with a few ifdef's.
> - the total lack of support to make such usage easier for non C compiler
>   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? 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).

>
> Main reasons:
> - the free unices are more stable, there is some unification and
>   standarisation process going on.
> - OS X. For various reasons it was decided to keep to libc, mainly because
>   Apple can change the kernel interfaces easier. This also means we have
>   some basic infrastructure for the change in place.
> - the tendancy to put more functionality  in (merge libs with) libc. This
> is bad IMHO, however a fact. (think userland threading libs, NIS and other
> multi-machine authentication support, unicode, internationalisation).
> - FPC is more advanced, the avg programs have become more complex, and
>   longterm quite a lot will link to C libraries and therefore libc anyway.
>   (e.g. lazarus because of gtk.)
> - keep the syscall interface, because it makes small stuff and
> bootstrapping so much easier.
>
> > I assume there is a provision for FPC to interface with C isn't there?
>
> Of course it can. How do you think lazarus interfaces with gtk?

That's what I thought, but I was beginning to wonder.


> But the exact answer depends how you see it. You can't use C headers and
> simply try to call the functions listed in them. You'd have to convert the
> headers to their pascal equivalent, and there are some semi automatic ways.
> Then you can link to C. Look for the existing headers (like the gtk
> interface that lazarus uses)

OK, this is what I expected.

> 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 :) 

>
> So it is like having a mold (headers to use with C programs), but not be
> able to use it to make some special form (Pascal programs). However by
> looking at the original mold, you can make a better fitting one for the
> special form.

Nice analogy.

>
> Linking directly (as opposed to via C or the C++ CEXTERN or what its called
> way ) with C++ and Objective C is not possible yet. Some other languages
> might be possible through their C compability.
>
> You can of course try to revert to asm to write the interface. It is the
> only other language that FPC directly supports.
>
> 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. 

> (Marco V is really tired now)

I'm tired just reading it!

> 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.

> 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). 

Thanks for taking the time to write this huge response.

Chris Bruner

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