? libltdl's lt_dlopenext() loads modules given the base name
without the file extension, which takes some pain out of portability.
Fang
David Fang
http://www.csl.cornell.edu/~fang/
http://www.achronix.com/
___
Autoconf mailing list
Autoconf@gnu.org
e: ./configure YACC=/my/yacc ...
I've attached my m4 macro for testing whether $YACC is really bison or
yacc, not just relying on the program name.
automake also provides a helper script 'ylwrap' to deal with yacc/bison
compilations and do some file renaming.
Fang
David Fang
http
of hooking some post-reconf script/actions to
autoreconf? There's *gotta* be something simple here, but I thought I'd
throw the question out before I concoct some dirty hack.
Thanks in advance!
David Fang
___
Autoconf mailing list
oving it manually everytime on Makefile?
Hi,
I think a combination of
AM_CXXFLAGS =
and
configure CXXFLAGS=""
will work.
Probably just the latter is enough.
I believe -g and -O2 are picked up by default by autocon
Hi,
What if you capitalized SUBDIRS in Makefile.am? (That's how it
looks in all examples I've seen. :) )
> The top-level Makefile.am is a one-liner:
>subdirs = src
> and the src/Makefile.am is also a one-liner, pointing to the two
> subfolders:
> subdirs
7;d rather have these variables isolated
from config.h. Another idea could be to provide an option in AC_DEFINE to
retarget to another file besides the default "config.h"?
Any ideas?
David Fang
___
Autoconf mailing list
A
ring the move-if-change useless (always finds never changed).
Is this what you meant? Admittedly, I'm sure how to use a
stamp-file in this case (I've only hacked my own stamp schemes for
completely different situations in Makefiles).
David Fang
__
> Is this what you meant? Admittedly, I'm sure how to use a
> stamp-file in this case (I've only hacked my own stamp schemes for
> completely different situations in Makefiles).
Sorry, last post should've read:
I'm UNSURE how to use a stamp-fil
xcept that there will be no foo.h: foo.h.tmp dependency
automatically generated to auto-reconf, which would be nice. It's not
difficult to add the rule in the Makefile.am manually, but it's just one
more thing to remember (and explain to someone reading through my files).
I
keep around a "rm `find ...`" script for removing maintainer-files to that
I don't have to configure-generate a Makefile before maintainer-cleaning,
which is extremely rare (for me).
David Fang
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
t;(or a newer version if it is available)"
DIE=1
}
if test "$DIE" -eq 1; then
exit 1
fi
test $TEST_TYPE $FILE || {
echo "You must run this script in the top-level $PROJECT
directory"
exit 1
}
libtoolize --copy
sn't clean most of the generated files.
>
> Second, maintainer-clean has nothing to do with AM_MAINTAINER_MODE.
>
> (And, as I said in my post to another sub-thread, forget about
> AM_MAINTAINER_MODE, too.)
David Fang
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
te
universal libs/bins using the GNU autotools. I'd be grateful of some
documentation (manual section) came out of this thread.
David Fang
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Hi,
I naively tried to use AC_CHECK_FILE(S) on /dev/stdin /dev/stdout
and /dev/stderr to detect their presence, but the test result is 'no' for
these 'files'. The result is 'yes', however, for /dev/null.
Is there a more appropriate test for the presence of these special
files? or
> > I naively tried to use AC_CHECK_FILE(S) on /dev/stdin /dev/stdout
> > and /dev/stderr to detect their presence, but the test result is
> > 'no' for these 'files'.
>
> These are not real devices. You may find entries in /dev, which
> suggest otherwise, but look closely: if they exist at all, t
> > To give a little more context for what I'm trying to do in C++
> > (experimentally): I've discovered that std::ifstream foo("/dev/stdin")
> > results in a file stream that works just like cin, likewise for stdout,
> > etc... Just like in standard C, one could use stdin, stdout, stderr as
>
> Whether /dev/std{in,out,err} are devices, symlinks, or even present
> is going to be system dependent.
>
> They're real character devices on NetBSD:
> $ ls -l /dev/std{in,out,err}
> crw-rw-rw- 1 root wheel 22, 2 Feb 19 11:01 /dev/stderr
> crw-rw-rw- 1 root wheel 22, 0 Feb 19 11:01 /dev/stdi
> Yes (without having tested it). A couple of very minor nits inline:
>
> > AC_DEFUN([AC_CXX_STD_IFSTREAM_DEV_STDIN],
>
> Please do not name your private macro with `AC_*'. That's the "name
> space" reserved for macros from Autoconf proper. It's commonly seen
> to use ones initials or a project
> > Sorry for the confusion, I meant that the need to be *identical*, not just
> > derivable from the other, because I'm containing their objects (value),
> > not references.
> > struct foo { ifstream _stream; };
>
> I think you are making a design bug. An iostream is generally not
> copyable,
> Sometimes I wish to call configure with different flags. For example:
> ./configure CXXFLAGS="-ggdb -Wall -std=c++98"
>
> or
> ./configure CXXFLAGS="-O3 -funroll-loops" --with-gmp
>
> or some more like these. Having to be writing these all the time is
> cumbersome and error-prone since for debugg
> Andreas Schwab wrote:
> > Try ./config.status --version.
>
> Thanks! But how could I have guessed this functionality is available under
> this option?
> $ ./config.status --help
> ...
> -V, --versionprint version number, then exit
> ...
>
> Should better say:
>
> -V, --versionprint v
Hi autoconf-ers,
I'm having a problem configuring a project using -Werror because
tests for AC_CHECK_SIZEOF() all die in the following manner (excerpt of
config.log):
(These tests fail on FreeBSD 4.3 which doesn't have .
The AC_CHECK_HEADERS([stdint.h]) confirms this during configure.)
--
H", so that it now works with "gcc
> -Wundef -Werror". Problem reported by David Fang in
> <http://lists.gnu.org/archive/html/autoconf/2006-08/msg00045.html>.
> * doc/autoconf.texi (Header Templates, Default Includes):
> (Particular Functions, Ge
tributes, "hidden" and "default"
dnl New since gcc-4.0.
dnl Define HAVE_ATTRIBUTE_VISIBILITY_HIDDEN if supported.
dnl Define HAVE_ATTRIBUTE_VISIBILITY_DEFAULT if supported.
dnl
dnl @category Cxx
dnl @version 2006-05-08
dnl @author David Fang <[EMAIL PROTEC
On Tue, 22 Aug 2006, Jan Engelhardt wrote:
> Hi David,
>
> I am afraid using -Werror does not work, it really needs -fvis.. on the
> command line:
>
> $ cat x.c
> int __attribute__((visibility("hidden"))) mx(void) { return 1337; }
> $ cc -c x.c -Wall -Werror
> (No error)
> $ cc -c x.c -Wall -Werro
ling,
it may just be simpler to use what's available at make-time.
David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)
__
> On Saturday, January 20, 2007 @ 5:50p, Ed Hartnett wrote:
>
> > David Byron wrote:
> >
> > > Any suggestions how? I've seen people write scripts to
> > > modify/rename config.h but that seems overkill in this
> > > case.
> >
> > How about something like:
> >
> > #ifndef MY_CONFIG_INCLUDED
> > #i
27 matches
Mail list logo
