Robert Lipe wrote:
>> First, 'system libraries' does not describe the software that comes out
of
>> ports. Software like expat is optional, and not, in the way the phrase
is
>> normally used, a 'system library'.
> Are you arguing that installing libraries in places that aren't searched
> by default and then expecting every application to search for it is a
> good idea? Sorry, I don't agree that adding compiler-specific flags to
> search for OS-specific installation defaults is any more correct for
> FreeBSD than it is for Mac/OS or Solaris, each of which puts them in yet
> a different such place.
No, I'm not arguing that at all. I'm arguing that applications that build
using libraries that aren't part of the system installation should be
prepared to look for those libraries in places other than where the system
libraries are placed.
"Every" application doesn't use expat, and those which do should be set up
to look for it.
> Could we do a better job of explaining how to cope? Surely. In almost
> every case, it's a one line change *for the user that knows where to
> look*.
It's a "one line" change that I coded in your makefiles and sent you a patch
for in August. It wasn't one line then and it's not one line now.
I did a better job of explaining how to cope when I provided you with
Makefiles that address this problem in August. You weren't interested in
fixing your mistake then, and I have no reason to believe you're going to
fix it now.
We're not talking rocket science here. We're talking the very basics of
writing code that's intended to be compiled on multiple systems. Guess
what? they don't all have gmake and they don't all put their libraries in
the same place and they don't all allow users to move libraries to wherever
they want them.
You're tilting at bigger windmills than you'll ever cope with if you think
that all of a sudden all of those systems are going to change their behavior
because you don't want to code proper makefiles.
>> Second, /usr/local has been in successful use for the purpose intended
for
>> something on the order of 20 years.
> I agree. Then on such systems /usr/local should be searched by default
> if the system is going to put provided libraries in /usr/local/. (And
> stuff in "ports" is 'provided' since I didn't build it.)
You don't seem to understand the purpose of having non-standard places to
put libraries. The whole idea is that you only search for default things in
default places. If it isn't part of the standard system, you don't want it
to be searched for by default.
>> Fourth, the compiler has -I and -L directives (and has had since the
early
>> 80s,) precisely because there are libraries that aren't to be installed
in
> For the compiler that's on your system, that's true. Not every compiler
> supports -I and -L with the definition on your system.
These days I compile on windows, mac/os, os/x, linux, freebsd, and various
real time OSes. While the directives don't always take the form of command
line '-I' and '-L', they *always* exist. I am unaware of a C compilation
system that does not support searching for include files and searching
multiple library locations.
Hell, even C89 discusses the issue, indirectly.
>> Please don't assume that the young OS you are most used to is the
standard
>> for such things, and rest assured that what may appear to be 'silly' is,
in
> I'm not exactly a newbie at OS design. My day job is, in fact, OS
> design.
and yet you don't understand something as simple as what is a system
library?
OK, if you say you are, you must be.
> I'm sorry that I worked you into such a froth with the word "silly".
It wasn't the word "silly". It was the sheer cluelessness of your response.
>> I gave you a patch for this problem back in August, the last time I had
an
>> opportunity to spend any time with gpsbabel. It appears to have
>> disappeared.
>> I have a patch for both of the Makefile problems, and for the problem
with
>> maketm. Are you interested, or are they sufficiently silly to end up in
>> your bit bucket again?
> If you have a patch that's portable, doesn't rely on the specifics of
> FreeBSD, GCC, or any such thing, I welcome it. If you've submitted such
> a patch before and I've lost it, I apololgize.
(Hint: Adding -Iblah and -Lblah isn't it.)
Does the amazing degree of inconsistency in your position bother you very
much?
You claim that you want the code to be portable, and whine about '-I' and
'-L' and then you demand that one uses gmake.
I have news for you: the equivalent of -I and -L exist on more C compilation
systems than gmake does.
>> Well I'm sure confused. You rant that you want to write portable code,
but
>> you refuse to write portable Makefiles.
> Show me a patch to the Makefile that makes it work on your system as
> well as it works on everything else *without introducing additional
> system dependencies or substantial complexity* and I'll bring it in. I
> said at the time that libtool/automake isn't it, so if you have another
> approach, please show us.
In other words "show me a light that works without photons."
You're makefiles require gnu make because you use subdirectory targets. Fix
that so it's portable. It's trivial.
You can't even build gpsbabel on a non-gnu system because of the makefile
dependency and you're throwing up red herrings about -I and -L.
>> Just because I made a suggestion in the context of gcc, which is the
>> most common compiler in your world, doesn't mean that it's the only
>> C compiler that I use. I'm sorry that I thought my audience would be
>> intelligent enough to realize that the switches would be different for
>> different compilers and
> OK. The switches are different for different compilers. We know that.
> Show us how to invoke appropriate switches for the myriad of compilers
> out there *without special casing OSes* and you'll have solved the
> problem. I solved it by assuming folks interested in additional warnings
> (i.e. developers) would know how to turn them on without tormenting the
> users that couldn't.
I don't have any lights that work without photons. sorry.
>> You should do one before you commit broken code to CVS. It would save
>> you embarrasment and a lot of other people time.
> I can live with the embarrassment of a commit that I publicly questioned
> and reverted within 24 hours on New Year's Eve. I'm sorry that I've
> wasted your time.
You've wasted several days of my time and I don't for a minute believe
you're sorry about any of it.
> If you have productive ways of solving the FreeBSD problem (which really
> boils down to:
> A) changing one line in a Makefile
It's more than one line and it's more than one makefile
> B) typing 'gmake' instead of 'make'
Explain to me again why it's ok to *demand* gmake but you continue to want
tool set independence.
> C) not using the CVS tree-of-the-moment and then complaining loudly
> about exposed problem
I posted a note pointing out the code wouldn't compile. If your skin is so
thin that you think that's "complaining loudly" then you'd better get out of
the open source business, because I just might critique your code.
> I'd love to hear them.
No you wouldn't. You like the dark and don't want any photons in your light
source.
>> Don't get me wrong. I'm not trying to piss you off and I like FreeBSD.
>> I'm just not willing to cow-tow to it.
It has nothing to do with Free BSD and everything to do with making your
code base portable.
If you *really* wanted it to only be a small number of localized changes,
then you would adopt the make variables I tried to get you to introduce back
in August.
You don't.
You want the whole world to change its ways because you don't know how to
write portable makefiles.
but maybe you've got other users who need the changes, so i've attached the
patch file.
|