If making config.gues return useful/normal values is a goal, then lets get
rid of the cpu-vendor-linux-gnu braindamage and start returning the
documented (and IMO more useful) behavior, where the 3rd piece of the
CPU-VENDOR-OS string is the OS name/version.
Values like i686-pc-redhat7.2, for exam
> From: Harlan Stenn <[EMAIL PROTECTED]>
> Date: Sun, 08 Sep 2002 03:39:04 -0400
>
> If making config.guess return useful/normal values is a goal, then
> lets get rid of the cpu-vendor-linux-gnu braindamage
To do that you'll first need to fix the GNU coding standards, which
specify the behavior
> > If making config.guess return useful/normal values is a goal, then
> > lets get rid of the cpu-vendor-linux-gnu braindamage
>
> To do that you'll first need to fix the GNU coding standards, which
> specify the behavior here. (It is a controversial area, so you'll
> have to make a good case.
Just point people to www.mingw.org and it's Minimal SYStem package,
MSYS, and it's MinGW package. :)
Advantage:
: The configure script already executes properly.
: It's open source.
: It uses gcc+binutils+gmake.
Earnie.
I am trying to update the xine project library automake/autoconf system
to use autoconf-2.52 or above. In the m4 functions it has a function
called AC_CHECK_IP_MREQN defined below:
dnl AC_CHECK_IP_MREQN
dnl check for struct ip_mreqn in netinet/in.h
AC_DEFUN([AC_CHECK_IP_MREQN],
[AC_CACHE
Paul Eggert wrote:
>For most of those sorts of things it is better to use the Autoconf
>approach, where you test for the features that you need, rather than
>guessing the list of supported features from the canonical system name
Makes sense to me. And it shouldn't be that difficult to set up th
Still trying to get the hang of all this and
am looking for a clean project that creates several libs which are
located in directories at least two levels deep that I can use for an
example?
Any help much
appreciated.