[fpc-pascal]Graphics cards, VGALIB

[Marco van de Voort]

> On 5 sep 2004, at 20:17, Marco van de Voort wrote:

> >
> > This is no solution. I can use that, you can use that, 99% of our users
> > can't.
> 
> I was not thinking of requiring the users to write makefiles (I agree 
> we simply cannot do that). More that we call this stuff in the 
> makefile, put the results in an include file using some compiler 
> directives and store it in the ppu.

> However, that's also not a 
> solution, since the user won't be recompiling the gtk units normally. 

Yes, same reason why I moved it to the cfg file, and not have {$linklib xx
weight} in source.

> Unless we put in the command itself, store that in the ppu-file and 
> have the compiler always call it at compile-time.

I don't like this, because this is so gtk2 only. There is also SDL, and in
the future maybe a lot more "special" packages. I've had to rearrange
libraries for static linking on *BSD too. (e.g. to get a fully static
textmode IDE). Moreover what if gtk decides to add a linking parameter that
breaks FPC ? (it's not all -l statements). It would break linking of the
compiler.

How about crosslinking btw? I can transfer .so's and .a's to another machine,
but can not run something like "gtk-config" there.

> > after
> > a gtk version change.
> 
> I simply think the weights stuff will not solve it. It's handy if you 
> know beforehand which libraries will be used and which will always have 
> to be first, but who says that the linking order always has to be the 
> same?

That's why it is in configfile, and not 100% baked in. (though executing
gtk-config each time does)

> Especially in case the linker supports multiple namespaces and 
> one package needs symbol X from library A, and another one from library 
> B.

There is always some directed graph in dependancies that can be translated
into weights. But true, this kind of problems make having one weightfile 
a bit difference (since e.g. Mac OS X will probably be different). 

Some autogeneration of options (appended to .cfg) might be needed.

> > What is exactly wrong with having the weights somewhere? I never said
> > anything about make in compiler, since it is not an issue of make, it 
> > is an
> > issue of order of libraries.
> 
> I simply meant that our compiler does part of what make normally does 
> (figuring out dependencies, compiling different files, ...), but it's 
> not a full-fledged make replacement. And some kinds of things are 
> easier to handle with make (you don't even need configure for that), 
> since it can be told to call external programs to figure things out. 
> Our compiler cannot do that (yet?)

One aspect I don't like from this, is that directives to support that creep
back in the source. The weights system goes outside .ppu and source, and
only affects the linker backend as it should.

{$execute gtk-config}  ? :-)