Re: [ANNOUNCEMENT] New on sourceware: xpm-nox-4.0.3-1 (replaces xpm-4.0.0-2)

["Charles S. Wilson" <cwilson at ece dot gatech dot edu>]

Norman Vine wrote:
> 
> Charles S. Wilson writes:

> >This means that in order to link against the non-X-based Xpm libraries,
> >you must
> >  a) compile using '-I/usr/include/noX'
> >  b) compile with the '-DXPM_NO_X' flag
> >  c) link using '-L/usr/lib/noX'
> >In some cases, for instance 'configure'-based packages, you have to do
> >it this way:
> >  CFLAGS="-I/usr/include/noX -DXPM_NO_X" LDFLAGS=-L/usr/lib/noX
> >./configure
> 
> If it has to be it has to be but ...
> I find this rather ugly.

Yes. It is ugly. Sometimes life isn't pretty.
 
> Isn't there another way

There are many ways.  They are all ugly.
 
> ie it would make more sense to me < albeit a non X11 user >
> to have special 'X11' include and lib directories added to the front
> of the normal include and lib paths when compiling X11 applications.

This doesn't make sense to me.  There ARE special X11 include and lib
directories.  "/usr/X11R6/include" and "/usr/X11R6/lib".  However, you
can't shrug your shoulders and say, "Well, then X11 apps will use that,
"normal" apps will use /usr/include & /usr/lib.  Done".

Why?

Because X11 apps use BOTH /usr/X11R6/* and /usr/*.  Configure
automagically finds the /X11R6/ versions.   /usr/* is ALWAYS searched. 
ALWAYS.

So, somehow you have to instruct the package to "use /usr/* and
this-special-xpm-nox-directory but not /usr/X11R6*" or "use /usr/* and
/usr/X11R6* but not the special-xpm-nox-directory".

Previously, we played games with variant names for the import and static
libs, with temporary symlinks and other EXTREMELY ugly hacks.  And it
STILL conflicted with the versions distributed by cygwin-xfree.
 
> This should allow for transparent compilation of packages in both
> X11 and Win32 mode.

No.  it will not -- because it already exists and doesn't.  The only
thing that could make the new xpm-nox situation slightly less ugly is to
contruct its version of xpm.h to automatically #define XPM_NO_X, but
doing that would break the configure scripts of packages that already
know about the flag and take special steps (like XEmacs).

Rule #1: don't break stuff that's already working, without a REALLY good
reason.

Rule #2: "that's ugly" is NOT a good reason (unless we're talking about
the linux kernel, and your name is Linus)

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple