On 17 Jul 2006, at 16:01, Daniël Mantione wrote:
As I said, you do not have to parse that unless you have an
internal linker.
And even then you only have to parse linker options for the
platforms you
support. Also, depending on which gtk you link against on Mac OS X
you may
need to link umpteen gtk/gdk libraries, or need a "-framework Gtk+-
Cocoa" or
similar linker switch (which would be hard to support with
Marco's approach).
Ok, with gtk-config the right way to get the libraries is "gtk-
config --libs".
With tclConfig.sh you have to source that in a shell script and read
environment variables afterwards.
So, in order to support this, we would need to write a hack when a
{$linklink gtk} occurs and write gtk-config specific code. For a
different
library we would need a different hack.
Of course not. You should never change a {$linklib magicstring} into
some command. The exact command(s) to be executed would have to be
embedded in the unit with a compiler directive (and probably, just
like library name, be ifdef'd per platform).
Also, fact is we do have an internal linker and it will hopefully be
used for most platforms in the future.
I do not see this happening any time soon for e.g. Mac OS X.
Ultimately it will go in the same
direction as with the assembler readers even for external linkers: In
order to fully understand the parameters, the compiler must understand
them.
Yes, this is a downside of integrating everything (with the upside
being speed and memory usage, obviously).
Generate 3 units, and introduce some unit aliases for gtk like
Marco did
for libraries, problem solved. That is still a lot more generic
‹solution
than *-config and a lot less work.
Of course making the developer type in everything manually is always
more generic and less work for us. That is not my point, and I'm not
against providing this functionality. As I said in my reply to Marco,
I consider it complementary, as a last resort if all else fails.
It's not just gtk which uses this, at east sdl also does. And the
fact that it
doesn't solve world hunger does not mean it's not useful to
support it.
We should design a system that does solve world hunger. I'm serious
about
that: if we want to be a more professional tool than C, we should
not copy
the defficiencies. Makefiles are one of them, Autohell is another, and
I consider this one such a thing as well.
I think all this "competing with C" and not-invented-here syndrome is
downright silly, along with all the claiming that most bad things
come from C. If anything, it comes mostly from the standard Unix
design philosophy (small, well-delineated tools which perform their
core function and *only* that core function). Most *nix C compilers
follow that principle very well, but other C development environments
are more integrated (like commercial Mac and Windows IDEs, where you
sometimes can hardly e.g. tell the compiler from the linker).
We are only a small team, and by playing the elite Pascal geeks who
are going to show how much the C world sucks by doing everything
different, we are going to
keep getting stuck by having to reimplement everything because we
cannot work with what is already there. People often talk about how
stupid Mac users supposedly are and how elite they consider
themselves. Well, this Pascal-elitism and C-hostility by some gives
the Pascal community just as bad a name, even though just like in the
Mac community most people probably couldn't care less about these
little superiority wars.
To get back on topic: the more hacks you add to work around already-
existing infrastructure "because we don't want to rely on external
tools", the more you force yourself to keep doing that more and more
forever in the future. If you like that, fine. I don't.
The problem in this particular case is not C, it is the way most OS's
(do not) support library management. There are various workarounds to
make it less painful, and this *-config script thing is one way which
is fairly straightforward and which is being adopted in various
places (sometimes even fairly general, grouping everything together
in a global pkg-config script). Adding support for using this
existing infrastructure is good if it can help solving some problems
without people needing to know the nitty-gritty details of how the
libraries are called on their system.
Still, you can put some autodetections in samplecfg, but the
compiler
itself is really the wrong location to do so.
samplecfg only works at install time of the compiler, which is the
wrong time.
People don't decide at install time which package, which variant
and which
version of it they will want to use one day.
The compiler or linker is the only right place to do it (unless
you wrap the
whole thing with a configure script and Makefiles, in which case
you can do it
there -- but our compiler largely replaces exactly that).
This we agree on, the compiler should do the work.
Above you said that the compiler is the wrong location?
Anyway, I never said I agree with this principle (although it sure is
very convenient in a lot of cases, in others it's very annoying
because it requires that you roll your own solution for everything).
I simply said this is how the compiler works.
Jonas_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
