[fpc-pascal]Graphics cards, VGALIB

[Jonas Maebe]

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

>>> Setup could run gtk-config and stuff it in the files. Then at least 
>>> we
>>> keep the compiler free from such patchwork, and center the "ugliness"
>>> in the weights file that can be operated on by the user, external 
>>> tools
>>> etc.
>>
>> Until someone upgrades his libraries and the next compile will be
>> broken again. You have to work with makefiles to get around this.
>
> 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. 
Unless we put in the command itself, store that in the ppu-file and 
have the compiler always call it at compile-time.

> The chances that the users get into problems with complex makefiles 
> etc,
> is much harder than to have to tell them to run "fpcupdateweights" 
> 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? Especially in case the linker supports multiple namespaces and 
one package needs symbol X from library A, and another one from library 
B.

>> The C-style building by default is simply more flexible in this 
>> regard,
>> because the compiler is dumber and you can do whatever you want in the
>> makefiles. If the compiler largely takes over make's job and you don't
>> want to deviate from this, there is no way but to build in more
>> make-like functionality in the compiler.
>
> 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?)


Jonas