Re: GNU make or portable make? (was: Makefile to Makefile.am)
I for one would be glad if automake required GNU make, since it could make use of a lot of useful features which currently aren't allowed. Similar to autoconf not requiring a POSIX shell, depite the fact that non-POSIX shells are so far obsolete they are irrelevant. Are there any tools to spot GNUisms in Makefiles? If not, it seems like this would be a useful thing to develop.
Re: call for help/crazy idea: nmake support
On 8/1/2010 2:11 PM, Ralf Wildenhues wrote: So let me rephrase the question: if we have the ability to build completely with MSVC within a shell environment such as MinGW/MSYS would people still need something like nmake support? Speaking for myself and my projects -- no, I would not.
Re: Building prog first
On 3/22/10 6:50 PM, John Calcote wrote: Reuben, you've just hit upon one of the two most significant problems with Javadoc and the like (including doxygen, man pages, and info pages): Agreed -- which is why I think it would be wonderful if there was strong Autotools support for literate programming. Unfortunately, my m4-fu is not strong enough to figure out the appropriate macros to discover ctangle, cweave, etc. smime.p7s Description: S/MIME Cryptographic Signature
Re: Report to stdout like Linux kernel compilation does
Bob Proulx wrote: To give you a different perspective, I *hate* that format because it hides problems and *makes debugging harder*. I want to see exactly the command that was executed. I want to see the entire command. I don't want to see an abbreviation of the command. Fortunately, no one is advocating the current formatting be removed or even altered, only that a less spammy alternative exist. Always build with full warnings enabled. Always clean up warnings as they are introduced. Always keep a warning free build. Given the wide leeway the C and C++ standards give implementors in respect to what is warning-worthy, I think this is crazy. There are far more compilers in the world than just GCC, and trying to make a warning-free build on /every/ platform is just far too much torment-of-the-damned for far too little benefit.
Re: Bison C++ parsers and ylwrap
Ralf Wildenhues wrote:
It probably is a bug. I for one use bison/yacc very sparingly only and
lack the experience how to deal with it portably. Which is why it would
be better if someone else worked on fixing it.
For whatever it's worth, I have always found bison's C++ support to be
sub-par. It's always been easier to create C source from bison, put
some 'extern C' decls in the %{ %} header of the .y file, and output
to a .cc file.
So while I have no resolution for the bug, I would encourage you to just
use bison conventionally as a workaround.
Re: How to build source code while treating all warnings as errors with automake...
jasond wrote: Recently, I converted the project over to using Autotools and am wondering if there is a portable way to instruct automake to generate Makefiles that build code while treating all encountered warnings as errors? Probably so, and I'm sure Ralf will know what it is. However, this is usually not a very good idea. You have no idea what compiler someone's going to be using or what warnings it will throw. For instance, passing -Wall, -Wextra or -ansi to Solaris CC will give a warning. E.g., CC: Warning: Option -Wall passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -Wextra passed to ld, if ld is invoked, ignored otherwise CC: Warning: Option -ansi passed to ld, if ld is invoked, ignored otherwise ... So by enforcing strict checking and flagging errors on warnings, you are making sure that your code cannot compile out-of-the-box on Solaris.
Re: autotools on mac os x
Could you give me an hand, i have been searching for 2 entire days.. Try Fink. http://fink.sourceforge.net
Sablotron and Autotools?
For a project I'm working on, I need a crossplatform XML inspector. GDOME2 is out because it doesn't work on OS X, so we're instead looking at Sablotron. Looking at the Autoconf Archive I don't see any m4 macros for Sablotron, nor does it come with a pkg-config file. What is the canonical way to test for the existence of libsablot with autoconf 2.60?
Can't find the correct set of libs on FC5/x64
I'm currently taking a course in graphics programming with OpenGL, and
thought it would be kind of me to turn in assignments which are
./configurable. My desktop environment is an OS X box, and the TAs are
running a variety of different Unices.
This seems like a job for Autotools, so I set up a minimal environment.
I'm not an Autotools geek by any stretch of the imagination, but
getting it running under OS X involved not very much pain at all.
However, it bombs under Fedora Core 5 on x64. Apparently it finds
different libraries (both 64-bit and 32-bit) and tries to use both sets
simultaneously for linking purposes, which is causing no end of heartbreak.
The minimal environment is set up as:
template/ --+
|
+ src/
The template/configure.in:
AC_INIT(src/test.cpp)
AC_CONFIG_HEADERS(config.h)
AM_INIT_AUTOMAKE(rjh-hwk, 1.0)
AC_PROG_CC
AC_PROG_CXX
AC_PROG_LIBTOOL
AX_BOOST([1.32.0],[],[AC_MSG_ERROR([Package requires the Boost
libraries.])])
AX_CHECK_GL
AC_OUTPUT(Makefile src/Makefile)
The template/Makefile.am:
SUBDIRS=src
The template/src/Makefile.am:
AM_CFLAGS=${CFLAGS} ${PTHREAD_CFLAGS} ${GL_CFLAGS}
AM_CPPFLAGS=${CPPFLAGS} ${PTHREAD_CFLAGS} ${GL_CFLAGS} ${BOOST_CPPFLAGS}
LIBS=${BOOST_LIBS_R} ${GL_LIBS}
CC=${PTHREAD_CC}
bin_PROGRAMS=hwk_1
hwk_1_SOURCES = test.cpp
And, finally, the error I'm seeing:
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -o hwk_1 test.o
-lGL -L/usr/X11R6/lib64 -lX11
g++ -g -O2 -o hwk_1 test.o /usr/lib/libGL.so -L/usr/X11R6/lib -lm
-lXext -ldl -L/usr/X11R6/lib64 -lX11
/usr/lib/libGL.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[2]: *** [hwk_1] Error 1
make[2]: Leaving directory
`/mnt/nfs/fileserv/grad/rjhansen/Projects/22c151/template/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/mnt/nfs/fileserv/grad/rjhansen/Projects/22c151/template'
make: *** [all] Error 2
... Can anyone give me a simple Autotools solution to these build woes?
Also, if there are any style pointers on how to make this setup more
canonically correct (while still being readable to a non-wizard), I'd
welcome any corrections.
Thanks much for any help you can provide.
