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

Reply via email to