Re: [Lzip-bug] build issues - AIX and not gcc

[Michael Felt]

On 11-Feb-17 03:07, Antonio Diaz Diaz wrote:
> Hello Michael,
>
> Michael Felt wrote:
> > I know (i.e., just read) you are not a GNU project - so that explains
> > why the configure arguments are not working.
I stand corrected - "not working" should be "warns about". Many gnu 
projects silently ignore these "standard" arguments. And frankly, I do 
not know if one way is "better" than the other. Eye of the beholder.

In any case - you are quite correct that this is working.
> AFAICT, the configure arguments are working as expected. It just warns 
> about the options it does not recognize because it does not need them. 
> See 'configure --help':
>
> -------------------------------------------------------------------------
> Usage: configure [options]
>
> Options: [defaults in brackets]
>   -h, --help            display this help and exit
>   -V, --version         output version information and exit
>   --srcdir=DIR          find the sources in DIR [. or ..]
>   --prefix=DIR          install into DIR [/usr/local]
>   --exec-prefix=DIR     base directory for arch-dependent files 
> [$(prefix)]
>   --bindir=DIR          user executables directory [$(exec_prefix)/bin]
>   --datarootdir=DIR     base directory for doc and data [$(prefix)/share]
>   --infodir=DIR         info files directory [$(datarootdir)/info]
>   --mandir=DIR          man pages directory [$(datarootdir)/man]
>   CXX=COMPILER          C++ compiler to use [g++]
>   CPPFLAGS=OPTIONS      command line options for the preprocessor []
>   CXXFLAGS=OPTIONS      command line options for the C++ compiler 
> [-Wall -W -O2]
>   LDFLAGS=OPTIONS       command line options for the linker []
> -------------------------------------------------------------------------
>
>
> > However, assuming that CXX is c++ when g++ does not work - "is a bug".
>
> Lzip's configure does not try to guess the name of the compiler. It 
> leaves the user specify it as in '/configure CXX=xlc++'. Making 
> configure guessing things is error prone and inefficient. Lzip can be 
> configured, built and tested in less time than it takes for gzip's 
> configure to run.
Actually, that only works if ${CXX} --version works. When it does not, 
CXX=c++ is assigned.

address@hidden:[/]xlc++ --version 2>/dev/null
address@hidden:[/]echo $?
249

And, more directly - it starts by always assuming CXX=g++ - even with 
CXX set to something else in the environment:

CXX=g++
CPPFLAGS=
CXXFLAGS='-Wall -W -O2'
LDFLAGS=

# checking whether we are using GNU C++.
if /bin/sh -c "${CXX} --version" > /dev/null 2>&1 ; then true
else
        CXX=c++
        CXXFLAGS='-W -O2'
fi


> > And I cannot explain why gnu make is needed - except perhaps .cc might
> > not be recognixed as an automatic "source" for .o by POSIX make. (Not a
> > bug of yours - just something to be aware of).
>
> I think that requiring GNU make is more or less standard for GNU 
> packages because of the limitations in other makes.
Statisically, (from my packaging of 40 to 50 OSS packages - about 1 in 
20 requires it, usually due to a Makefile syntax using ::

As the issue is that $< is not expanded to foo.cc I would assume that 
.cc is not in the "OEM" make RULES.

Just an FYI - errata - surprise people at a dinner party with your 
obscure makefile knowledge. In other words, just sharing about something 
that will only happen in a non GNU/Linux environment.

> Best regards,
> Antonio.
>
> _______________________________________________
> Lzip-bug mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lzip-bug