"Lars J. Aas" wrote:
> : Does anybody sees a means to compute this at compile time? Using the
> : same trick as we did for SIZEOF etc.
I did need a cross-compile AC_C_BIGENDIAN once upon a time, so there is a
AC_C_BIGENDIAN_CROSS submitted to the autoconf-archive (hopefully Peter
will update the
Pavel Roskin wrote:
>
> Hello!
>
> > ] if test -f conftest.c ; then
> > if ${CC-cc} conftest.c -o conftest.o && test -f conftest.o ; then
> > if test `grep -l BIGenDianSyS conftest.o` ; then
> >echo $ac_n "looks big-endian ... " 1>&AC_FD_MSG
> >ac_cv_c_bigend
d the code have a chance to go into main' autoconf anyway,
or better leave it to some AC_C_BIGENDIAN_CROSS in the autoconf-archive...
Guido Draheim wrote:
> that happen... hmm... unicode-only host-platform? Anybody seen that? It
> seems I am locked to much with the 20 platforms I have around me... ;-)
Bernard Dautrevaux wrote:
>
> BTW, having such an automatic default option shoudl be nice for almost all
> tests; I know I can just "ac_c_bigendian=yes ./configure" but I never knows
> the name of the config.cache variables, so "./configure --set-bigendian=yes"
> coudl do the same.
a pre-sett
Bernard Dautrevaux wrote:
>
> Sure enough; I constantly forget this, probably because I *never* run
> configure manually but through a script in the build tree (and BTW type
> "./configure" instead of "make reconfigure" as my scripts usually
> automatically call aclocal/autoconf/automake)
Well, i
Richard Stallman wrote:
>
> The most
> important example is when `configure' is re-run (which is not that
> uncommon; re-running `./config.status --recheck' when configure.in
> changes is becoming more and more common): any such variables set in
> the command line are lost i
Akim Demaille wrote:
> See AC_ARG_VAR.
taken. ... then again, AC_CACHE_CHECK does not use it wouldn't that be okay?
Just again, what about a second-level options that go in another helpscreen, and,
well, in that respect, I do support your position to the point that the
current helpscreen is al
Peter Eisentraut wrote:
> Akim Demaille writes:
> > Does anybody know whether using fopen (foo, "wb") is portable?
> Extremely doubtful.
The "b" is an ansi-C requirement, however there may be some systems
that are simply not compliant. AFAICS these are quite old, somewhere
in the eighties or so -
Guido Draheim wrote:
> The "b" is an ansi-C requirement, however there may be some systems
> that are simply not compliant. [...] I just
> found second hand information that some DEC ultrix libc did barf
> at "b".
I did a bit of web digging, and I found first h
I am currently waiting for an announcement on the autoconf-list
for an information that the move is complete. The old place
however responds and it is obviously up to date.
If anyone is interested, I go used to use a set of autoconf-extensions
for more than one project of mine, and I had a need
I develop libraries quite a lot, and the installed headers do often
have dependencies on other system headers that may or may not be
installed there. It would be a nuisiance to write a series of
common.h.in headers if the library starts to get a little bigger.
Therefore I created the AC_PREFIX_CO
Hi everyone,
in the last days I did hit a problem that I thought was good to
do with an autoconf-macro - may be someone has already done
such a beast. It goes about the number of arguments to mkdir(2).
While every unix (posix?) system takes two arguments (the
filename and the modebits), quite a
ADL's version looks good - atleast for mkdir as it is okay to
put a single string at mkdir. I did overlook this one as
I had problems with -fwrite-strings and vxworks headers
that declare mkdir(char*), however ac-compile checks
wouldn't use that compile-option...
Otherwise, yes, there are good
...just a short question - is there possibly a configure GUI
somewhere? Something that parses "configure --help", shows a
nice GUI to change the options, and offers ability to run
configure $options, make and make install. No, I don't mean
something that can do anything about configure-options,
Akim Demaille wrote:
> [...] Autoconf 2.49c, our release candidate. The core Autoconf
> is not expected to change before the release, while the documentation
> and minor details still need some work.
> [...]
> Autoconf can be downloaded from
>
> ftp://alpha.gnu.org/gnu/autoconf/autoconf
Hi everyone,
has someone somewhen written some ac-macro to detect the
subpaths of a prefixed installation? The idea is to have
a moveable package where the compilation prefix path is just
the default that can be changed at runtime.
hmm, consider a package named 'foo' that has a bin/foo,
a lib/
Alexandre Duret-Lutz wrote:
>
> >>> "Dean" == Dean Hoover <[EMAIL PROTECTED]> writes:
>
> [...]
>
> Dean> Another thing you could do is make multiple build directories
> Dean> and always make in a certain way in them. In other words, you
> Dean> could:
>
> Dean> mkdir debug-build opt-build
Kevin Ryde wrote:
>
> #define __need_size_t
> #include
> #undef __need_size_t /*NOTATEMPLATE*/
#ifdef __undef_need_size_t
#undef __need_size_t
#endif
BTW, if you want to install a config.h file, you may want to use this:
http://pfe.sourceforge.net/autoconf/ac_prefix_
Hi everyone,
I have been updating my aclocal backpacker package, renaming it
to "aclocal-archive". Now it can create some rpm files for binary
distribution of aclocal macros for your convenience too. I would
like to have some comments on the usefulness of the aclocal-archive,
idea and I would l
Guido Draheim wrote:
> [..] I would
> like to have some comments on the usefulness of the aclocal-archive,
> idea and I would like to know if some people want to share it, [...]
> [..] http://216.136.171.200/pfe/aclocal-archive-0.4.3.tar.gz
180 downloads, no comme
a) automake was not ported from perl to guile for years,
and I don't know of experiments to actually do it now,
or have it done in this decade (it wasn't in the last).
Moving it from perl to guile does not earn much for
features or maintainability - it would just be another
point
Eric Siegerman wrote:
>
> On Fri, Apr 20, 2001 at 02:52:08PM +0200, Lars J. Aas wrote:
> > Does such a thing exist? Should it be a goat?
> > I'm thinking of something to stick on the web pages...
>
> Hercules slaying the hydra :-)
or just the hydra :-) well, there's just that impression
o
"Gary V. Vaughan" wrote:
>
> On Wednesday 16 May 2001 9:27 pm, David Burg wrote:
> > Hello,
> >
> > I need to change a existent configure.in file to enable cross-compiling
> > (host is x86 and target is strongarm). I have read the on-line documention
> > of autoconf on www.gnu.org, but explainat
Bruno Haible wrote:
> [...]
> Another totally different approach is to recommend that every
> library libfoo comes with a script 'foo-config' in /usr/local/bin that
> can spit out the required -I and -L options. Here as well, autoconf
> support would be nice, so that the resulting -I/-L options w
You are doing fine, just some configure-checks are not ready
for cross-compiling, and that's what you are warned about.
Basically, the package that you are trying to cross-compile
has not been made ready for cross-compiling.
Two approaches:
a) learn about config.site or cache-file, and let it co
This is not restricted to borland compilers, there are quite
some C-compilers on unix-systems that quite some people like
to see supported, however most of the autotools developers
do live in a quite gnu'ish/gcc'ish environment, and every now
and then, a gmake'ish/gcc pecularity slips in that wil
"Matthew R. MacIntyre" wrote:
>
> I want to have a configuration file in the sysconfdir for my program,
> but if I put AC_DEFINE(CONFFILE, "$sysconfdir/file.conf"), I end up
> with the path being "${prefix}/etc/file.conf" which is pretty
> meaningless to C. I've seen people hack it by just sayin
Rüdiger Kuhlmann wrote:
> AC_SUBST([infodir],['${prefix}/info'])dnl
> +AC_SUBST([htmldir],['${prefix}/share/doc/html'])dnl
> +AC_SUBST([psdir], ['${prefix}/share/doc/ps'])dnl
> +AC_SUBST([dvidir], ['${prefix}/share/doc/dvi'])dnl
> +AC_SUBST([guidedir], ['${
Russ Allbery wrote:
>
> Rüdiger Kuhlmann <[EMAIL PROTECTED]> writes:
>
> > I'd like to re-kindle the discussion about options for where to put a
> > programs documentation by suggesting the following patch:
>
> Wouldn't some sort of general facility for adding a new *dir switch for a
> given pa
Earnie Boyd wrote:
>
> Rüdiger Kuhlmann wrote:
> >
> > Hi!
> >
> -8<-
> > AC_SUBST([infodir],['${prefix}/info'])dnl
> > +AC_SUBST([docdir], ['${datadir}/doc'])dnl
> > AC_SUBST([mandir], ['${prefix}/man'])dnl
> >
>
> In my simplistic mind having three places for document
Ralf Corsepius wrote:
>
> Guido Draheim wrote:
> >
> > Earnie Boyd wrote:
> > >
> > > Rüdiger Kuhlmann wrote:
> > > >
> > > > Hi!
> > > >
> > > -8<-
> > > > AC_SUBST([infodir],['${pr
Alexandre Oliva wrote:
>
> > which leads me to the question where the /doc should go under,
>
> Perhaps instead of --docdir we should have --doc-prefix, that defaults
> to --prefix? Then man, info, html, etc would all be in /usr/local by
> default, but this could be easily overridden using --d
Paul Eggert wrote:
> [...]
> does OpenSSH 2.9p1. So AC_C_BIGENDIAN works only for native compiles.
> [...]
> Also, if you want to throw in cross-compiles for Solaris 8 while
> you're at it, append "|| defined _BIG_ENDIAN".
>
The topic of cross-compiling with ac_c_bigendian has been on the list
Do I understand it correctly that one would have to create the
config.h.in template file manually? Hmmm.
May I put a pointer here to that alternative with a pkg-config.h
derived from standard config.h? It has served as a good basis for me.
http://www.gnu.org/software/ac-archive/Miscellaneous/a
Tim Van Holder wrote:
>
> > Nowadays, many shared libraries include a -config script e.g. libgtk
> > [...]
> > There is much duplication of code here. Anyone wishing to use this
> > scheme must duplicate the script and then amend it for their use, and
> > also convert the m4 macro as well, to A
-1.4b FAIL
autoconf-2.52,automake-1.4h,libtool-1.4 OK
I'd guess the bug is libtool.m4 related?
Bad interference with autoconf-2.52?
cheers
-- guido
_______
Guido Draheim, R&D <[EMAIL PROTECTE
Roger Leigh wrote:
>
> I have attached a rewritten ac_path_generic.m4 (AM_PATH_LIB), as well
> as an updated AM_CONFIG_LIBCONFIG. If they are OK, I'm willing to
> submit them to the archive. Any comments appreciated.
Hi Roger,
it took me a bit to get time to have a look - AFAICS your macro a
Es schrieb Raja R Harinath:
>
> You can usually use the following command to generate something more
> FHS compliant
>
> ./configure --prefix=/usr \
> --sysconfdir=/etc \
> --infodir=/usr/share/info \
> --mandir=/usr/share/man
>
> However this is not
Es schrieb Gioele Barabucci:
>
> On Monday 29 October 2001 01:56, you wrote:
>
> > correct, ... and at the same time, inconvenient for the quick builds
> > when carrying a tarball of my projects around. It should be then just
> > configure/make/make-install even for win32-target where the files
Es schrieb John Poltorak:
>
> For some reason I keep getting this error msg when running Make after
> configure:-
>
> *** Warning: File `config.h' has modification time in the future
>
> config.h has a timestamp one hour in front of the current time.
>
> Any suggestions about what could be cau
Es schrieb Bonzini:
>
> > So AC_HEADER_STDBOOL should remove any preexisting stdbool.h before
> > doing any tests that depend on stdbool.h.
>
> Fixed.
>
> > I don't see why this would be needed. `make distclean' can just
> > remove stdbool.h unconditionally.
>
> Right.
>
being a person who
ok that foggy
as they do look to me sometimes, cheers, guido
Es schrieb Bruce Korb:
>
> Guido Draheim wrote:
> > being a person who has been doing some tricky stuff with a generated
> > file called stdint.h, I would like to oject on generating a stdbool.h
> <>
> I agr
* autogen macros added
Bruce Korb's latest achievement in his autogen project resulted in some
fine macro pieces which I have added to an extra subcategorie in the
ac-archive sfnet-branch until it gets decided where to put them in the
gnu-branch. I did also add a crosslink to http://auto
[EMAIL PROTECTED] wrote:
>
> 1. How do i request a C99 compiler? Is there some variation on AC_PROG_CC?
Do never ask for a version declaration, always ask for a feature
you need - that is the basic principle of autoconf. Many features
being declared as C99 were present in the 1994-version of a
[EMAIL PROTECTED] wrote:
>
> On Sat, Oct 13, 2001 at 11:18:16AM +0200, Guido Draheim wrote:
> > [EMAIL PROTECTED] wrote:
> > > 1. How do i request a C99 compiler? Is there some variation on AC_PROG_CC?
> >
> > Do never ask for a version declaration, always ask
[EMAIL PROTECTED] wrote:
>
> On Sat, Oct 13, 2001 at 11:24:57AM -0700, Paul Eggert wrote:
> > > From: [EMAIL PROTECTED]
> > > Date: Sat, 13 Oct 2001 10:22:31 -0700
> > >
> > > AC_MSG_CHECKING([whether $CC accepts C99 declarations])
> > > AC_TRY_COMPILE([],[
> > > int x=0; x+=1; int y=0;
> > >
[EMAIL PROTECTED] wrote:
>
> On Sat, Oct 13, 2001 at 09:07:54PM +0200, Guido Draheim wrote:
> > > No, that's silly. i'm not going to litter my code with #ifdefs
> > > for old compilers. More realistically, i just want configure to
> > > suggest
[EMAIL PROTECTED] wrote:
> {..}
> Is this stylistically acceptable?
*fg* oh well, speaking about style is (of course) a matter of taste
and then a matter of whose taste it shall please. For a macro that
you want to reuse in your own projects, yes looks good.
Speaking as a maintainer of the (gnu
"Torok-1, Maria" wrote:
>
> Anything you could tell me regarding 32-bit and 64-bit versions of automake,
> make, and m4 would also be appreciated!
> [..]
> > E-mail: [EMAIL PROTECTED]
"Torok-1, Maria" wrote:
> We're currently using GNU libtool v1.4 on Solaris 2.6,
... before you flood the mai
ngw32 or cygwin environment over a windows box
> ([un]fortunately I do not own windows to do that).
>
> I hope someone here could point me some simple directions
> in how to do that, so that I can see what I am missing.
>
Guido Draheim wrote on Aug 2, 2001:
>
> Mumit Kh
Es schrieb "Richard B. Kreckel":
>
> Now four years into FHS-2.0, can we consider this a bug? Or is FHS buggy?
>
Didn't we had a lengthy talk about it lately? Well, actually, I wrote a
little macro that saves me the burden to place all the if/then/else
computations into a configure script agai
Es schrieb "Thomas Bushnell, BSG":
>
> Guido Draheim <[EMAIL PROTECTED]> writes:
>
> > Didn't we had a lengthy talk about it lately?
>
> So since I'm the main directories for the GNU Coding Standards, I've
> sent a note to RMS reques
Es schrieb "Thomas Bushnell, BSG":
>
> Harlan Stenn <[EMAIL PROTECTED]> writes:
>
> > There is more to software than GNU.
>
> Sure, but the GNU Coding Standards are for GNU, by definition. There
> are many things that are disallowed by them in the interests of making
> GNU better. For example
Es schrieb Russ Allbery:
>
> The vast majority of software installations by system administrators from
> source do not go into /usr, /etc, or anything else owned by the system.
> They go into /usr/local, /opt, or some other local path. /usr and the
> like are reserved for the system and its own
I did send an e-mail directly, and posted an answer publically to
news:comp.lang.c.moderated - it is really off-topic. cheers, guido
Es schrieb Kenneth Pronovici:
>
> I guess this is probably somewhat off-topic, but I'm hoping someone here
> can point me in the right direction. I apologize in
overkill.
Es schrieb "Fredriksson, Johan":
>
> Do I need to change the rules in autoconf.m4f and acspecific.m4 to get
> autoconf to support VxWorks. I have a package that I've built on Cygwin and
> Sun-Solaris, now I need to build it on VxWorks.
>
> If I need to do this where do I get Information about it
Es schrieb Dan Kegel:
>
> Guido Draheim wrote:
> >
> > overkill.
>
> Agreed. I'm tempted to say:
> Death to XML, long live *plain* text!
>
it's not quite xml that's bugging me - it's that the
intelligence needed to form a good html view
Es schrieb John Poltorak:
>
> Is there any place I can search to find if an app has been succesfully
> built with autoconf+friends on a non-Unix platform?
>
> I'm thinking of trying to build Tar 1.13 and see refences to DOS but have
> no way of telling whether they are purely historical, (going
hello clinton,
may I ask what you are *really* trying to achieve?
Personally, I would like to depracate to prefix a config.h file
in place, even more if you would really install it along with
your library - I've seen to many include-order conflicts for
this case, so please don't do that.
Second
Es schrieb Clinton Roy:
>
> Guido Draheim <[EMAIL PROTECTED]> writes:
>
> > may I ask what you are *really* trying to achieve? Personally, I
> > would like to depracate to prefix a config.h file in place, even
> > more if you would really install it along wit
o add
it to the main autoconf. Well, in that case, it should be
done right and true, not just done and useful ;-) ... so it
should atleast be able to add to config.status 8-] --guido
Es schrieb Guido Draheim:
>
> > option already. The other problem I can see with
> > AC_CREATE_PREFIX
o the problem, for making the checks
of autoconf available via a generated header that gets defined
through ac_define's. -- guido
Es schrieb Russ Allbery:
>
> Guido Draheim <[EMAIL PROTECTED]> writes:
>
> > I'm doing the same thing, and in fact, all libraries should
Es schrieb Russ Allbery:
>
> Clinton Roy <[EMAIL PROTECTED]> writes:
> > Guido Draheim <[EMAIL PROTECTED]> writes:
>
> >> ... the other problem is that the prefixing is not done during
> >> reconfig, and in fact, the items in my ac-macro should be a
Simon,
you contacted me about ac_create_stdint_h.m4 - no success with it?
-- guido
Es schrieb Paul Eggert:
>
> > From: "Simon Waters" <[EMAIL PROTECTED]>
> > Date: Thu, 21 Feb 2002 02:31:30 -
>
> > I need to define 32 and 64 bit integer types in reasonably portable C.
>
> I assume you me
while trying to create an rpm for the mp4h project, I jumped on the
following problem:
- the toplevel configure has configure.ac
- a subdir libltdl/ is copied in, which contains a configure.in
- the rpm macro %configure will expand to a line like
CFLAGS=$RPM_CFLAGS configure --prefix
- t
Es schrieb Alexandre Duret-Lutz:
>
> >>> "gd" == Guido Draheim <[EMAIL PROTECTED]> writes:
>
> gd> while trying to create an rpm for the mp4h project, I jumped on the
> gd> following problem:
>
> gd> - the toplevel configure has conf
--bindir vs. --libdir ?
Es schrieb Dan Kegel:
>
> I'm cross-developing. I want to build a package
> that has both static libraries and binaries.
> The binaries should go to the target system;
> the libraries should stay on the build system.
> What do I pass to configure and to make?
>
> If I
btool, with both static and shared libraries,
> in a cross-compile situation, without the static libraries
> leaking out onto the target system. We may need to split
> --libdir into --libdir and --buildlibdir, or something
> awful like that?
>
> Thinking about libtool and cross-
Es schrieb Dan Kegel:
>
> Yes. Doc and headers would stay on the build system.
>
> > It is however
> > uncertain, e.g. on some build hosts, you could not
> > read the manpages, while they are needed on the target
> > host. Or just the other way round, useless on the
> > target host, and useful
Peter Simon's mail does contain a lot of allegations - I will
refrain to clarify in the same length. I hope that quite some
people on the Autoconf list know me well enough to assume that
there had never been bad intentions whatsoever on my side.
Peter has been contacting me on Sunday to ask about
It is great that aclocal/autoconf can now m4_include multiple
files from a local m4/-subdirectory. Yet, I was missing a tool
to populate it. A while back I just modified the standard
aclocal to do that - i.e. instead of --ouput=FILE using an
--output-dir=DIR. However, as far as I can see, the curre
I have extracted some routines from the current AC-Archive
website engine (implemented in Python) to work standalone
on a single macro (or small number of macros if you like).
Given a macro ax_example.m4 you can now say
> ac_archive_macro_to_html ax_example.m4
which creates the output file ax_exam
https://sourceforge.net/forum/forum.php?forum_id=665363
> As of 2007-02-08, SourceForge.net Compile Farm service
> has been officially discontinued.
> We feel that our resources are best used at this time
> in improving other parts of our existing SourceForge.net
> service offering, and in introdu
Dirk schrieb:
> Guido Draheim wrote:
>> https://sourceforge.net/forum/forum.php?forum_id=665363
>>> As of 2007-02-08, SourceForge.net Compile Farm service
>>> has been officially discontinued.
>>> We feel that our resources are best used at this time
>>
Thomas Dickey schrieb:
> On Thu, 15 Feb 2007, Dalibor Topic wrote:
>
>> HP's test drive covers a bunch of platforms. For the rest: qemu,
>> vmware, aranym, hercules, gxemul, or (least desirable, imho) real
>> hardware.
>
> It's less than it was (about half the platforms went away last fall).
>
Reminder:
- http://ac-archive.sourceforge.net/guidod/ax_prefix_config_h.html
The macro creates a package config.h that can be installed.
It avoids to create a special ace-config.h manually.
Point the ACE developers to that as installing config.h is plain wrong.
And, use it yourself thereby avoidin
Eric Lemings schrieb:
> Hi,
>
> I want to write an Autoconf macro that checks for overloaded functions
> in C++ (assuming of course all basic C++ configuration checks have been
> done). For example, does the C++ compiler support function calls to
> abs() in or for all integer types ranging fr
Julian Cummings schrieb:
> Attached is a proposed patch for the autoconf macro ax_enable_builddir.m4.
> The patch universally replaces "host" with "build" and "HOST" with "BUILD".
> The rationale is that typically the user wishes to segregate builds based
> upon the BUILD target rather than the con
Peter Simons schrieb:
> Guido Draheim writes:
>
> > Peter Simons writes:
> >
> >> Hi Julian,
> >>
> >> thank you for taking the time to update the macro. Your patch
> >> certainly feels reasonable to me, so I applied it to th
Es schrieb Dan Kegel:
>
> Guido Draheim wrote:
> > > ...
> > > I don't think this does the trick, though. I can't see
> > > how it lets you install binaries and shared libs to a staging
> > > area for transfer to the target, and everything el
Es schrieb Dan Kegel:
>
> Guido Draheim wrote:
> > ... See - the libtool crossgcc support (to which I did
> > contribute some of the time) can simply ask the cross-gcc
> > for the local searchpath via `gcc -print-search-dirs` -
> > this is needed for win32
Es schrieb Guido Draheim:
> crosscompiling linux-to-linux). Now the result is simply
> grepped for the "libraries:" entry, at it usually spits
> out a couple of directories very close the installation
> of the crossgcc himself.
>
> [guidod@pc3 guidod]$ i386-mingw32-g
Es schrieb Paul Eggert:
>
> > From: Akim Demaille <[EMAIL PROTECTED]>
> > Date: 13 Mar 2002 11:23:10 +0100
> >
> > My question is merely one of interface.
> >
> > Currently
> >
> > AC_INIT
> > AC_CONFIG_HEADERS(config.h)
> > AC_CONFIG_COMMANDS(config.h, [echo Hello, world])
> > AC_OUTPUT
> >
> >
Es schrieb Clinton Roy:
>
> > > my_config.h: config.h
> > > sed 's/#define /#define MY_/; s/#undef /#undef MY_/' $@
>
> It would appear I can air my dirty code :)
>
> We define some of our own defines, that are already prefixed, so we
> have to take care of the case of double prefixing.
Es schrieb Akim Demaille:
>
> > "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>
> Paul> Sorry, I don't understand the question. I went back and read
> Paul> the thread, and I still don't understand the question.
>
> Sorry for being confuse.
>
> Paul> I did understand Russ Allbery's po
Es schrieb Paul Eggert:
>
> > Date: Sun, 17 Mar 2002 13:48:30 +0100
> > From: Guido Draheim <[EMAIL PROTECTED]>
>
> > your point is quite fine - why not let the lines
> > go into the makefile instead of config.status. I just wonder how to
> > do this
During the cooker developments of mandrake, I noticed they did create
a little script as /usr/bin/autoconf that would look for either
configure.in or configure.ac - if it finds the latter, it will
forward the call to /usr/bin/autoconf-2.5x, otherwise it will use
/usr/bin/autoconf-2.13, where of c
Es schrieb Akim Demaille:
>
> >>>>> "Guido" == Guido Draheim <[EMAIL PROTECTED]> writes:
>
> Guido> Or was that intentional for some reason - may be someone could
> Guido> enlight me whether autom4te based series and autoconf-2.13
> Guido
> Es schrieb Andrew Kiggins:
>
> Folks,
> I need to port some UNIX based code to an embedded OS (VxWorks).
>
> Autoconf/configure is the modus operandus for building the various
> UNIX flavours. To keep things nice I'd like to try to
> follow this module.
>
> Is it possible to generate configu
Es schrieb Peter Eisentraut:
>
> Akim Demaille writes:
>
> > What I'm doing now is buying my freedom. The freedom to extend
> > Autoconf without 1. requiring from the rest of the world that they
> > adjust their distclean rules, 2. requiring that Automake folks release
> > a newer Automake etc.
Es schrieb Yves Arrouye:
>
> Hi,
>
> I am running into a case where different Autoconf-based packages define the
> same macros, giving me plenty of warnings. Is there a way to prefix the
> AC_DEFINE'd names with some unique string (or maybe just the ones defined by
> Autoconf, such as the HAVE_x
Es schrieb "Mark D. Roth":
>
> On Thu May 16 05:59 2002 -0400, Thomas E. Dickey wrote:
> > aclocal has good intentions, poor design.
>
> I don't really understand why everyone says that like there's nothing
> we can do about it. If the design is poor and inconvenient, let's fix
> it! That is w
Es schrieb Paul Eggert:
>
> > From: "Mark D. Roth" <[EMAIL PROTECTED]>
> > Date: Thu, 16 May 2002 12:28:27 -0500
> >
> > That's fine, as long as it gets invoked automatically when you invoke
> > autoconf. It should all get done in one step.
>
> Personally, I dislike site directories since
> the
Es schrieb Stefan Seefeld:
>
> hi there,
> I'v got another question / bug report:
>
> I'm using the AC_INIT() macro with three
> arguments, which (even though it is not documented,
> as I wrote in an earlier post) generates a set of
> variables PACKAGE_SOMETHING that get automatically
> inserted
Before things get messy:
for a newbie it might be best to think of every shell command line
to expand into setting finally the integer-variable $? representing
the final value of the command. Therefore, a line like that written
below will expand to
$? = ( xxx == TRUE && yyy == TRUE )
and in a s
http://ac-archive.sf.net/C_Support/ac_prog_cc_warnings.html
see also
http://ac-archive.sf.net/C_Support/ac_prog_cc_strict_prototypes.html
http://ac-archive.sf.net/C_Support/ac_prog_cc_no_writeable_strings.html
Es schrieb Philip Willoughby:
>
> Hi all,
>
> I'm trying to write a pair of macros to
Es schrieb Viktor Pavlenko:
>
> Hello,
>
> I would like my program to know where it has been installed, in
> particular, the location of $datadir. Looks like a natural way to do
> it is to have a #define in config.h, like this:
>
> /*
> * myprog data directory
> */
> #define MYPROG_DATA_DIR "
Es schrieb Troy Cauble:
>
> I am cleaning up some autoconf scripts to support
> multiple builds against the same source, as in
>
>mkdir build_dir1
>cd build_dir1
>../configure
>
> In the middle of this large autoconf based project
> there's a third party module that does not use aut
Es schrieb Guido Draheim:
>
> Es schrieb Troy Cauble:
> >
> > I am cleaning up some autoconf scripts to support
> > multiple builds against the same source, as in
> >
> >mkdir build_dir1
> >cd build_dir1
> >../configure
> >
1 - 100 of 201 matches
Mail list logo
