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
_______________________________________________ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
