On Thursday 18 September 2008 06:07:28 'Ralf Wildenhues' wrote:
> > > I have performed a search for a conftest.obj file and it does
> > > not exist. As I mentioned in an earlier email, build of
> > > libtool failed to produce any .obj files.
> > >
> > > I have installed MinGW. Does it not have gc
On Saturday 20 September 2008 22:40:56 Matej Tyc wrote:
> > Then you need to use a macro that allows for specifying a header
> > to include. You can write one yourself, or try AC_CHECK_FUNC_IN
> > from the autoconf macro archive.
>
> By the way, do you have an idea what's the cause of this failiur
On Sunday 21 September 2008 21:12:22 Matěj Týč wrote:
> Thank you, Brian, I have sent your message to the macro author, so
> now it is really easy for him to fix it for others as well.
Why don't you just adapt it yourself, to suit your own requirements?
That after all, is the underpinning of the
On Friday 19 September 2008 21:31:15 Howard Larson wrote:
> > FWIW Ralf, I've just built autoconf-2.63 on an MSYS-1.0.11 box at
> > work. No errors in building. I've left the testsuite running,
> > but will not be able to report the final result until Monday; (I
> > don't use msw on my own boxes)
On Monday 13 October 2008 13:56:21 Eric Blake wrote:
> > The existing text is correct (albeit a
> > bit confusing in the automake-user's case where Makefile.in is
> > generated, so the upstream Makefile.am needs the modification
> > instead), so I'm quite sure what wording to use here, whether or
>
On Sunday 07 December 2008 20:35:05 Brian Dessent wrote:
> Jason Curl wrote:
Jason,
Your question has already been asked, and answered, several times
recently, on the MinGW and MSYS mailing lists; you would do well to
search their archives, e.g.:
http://thread.gmane.org/gmane.comp.gnu.mingw.use
On Monday 23 February 2009 01:39:52 Allan Caffee wrote:
> Indeed I tried a very similiar scenario using gcc 4.2.4 on Ubuntu
> (with a static library) and had the same problem.
Unsurprising, since you have specified your g++ command incorrectly.
> Was the error similiar to your original post? A l
On Monday 23 February 2009 04:26:11 Peter Johansson wrote:
> aaragon wrote:
> > aara...@aaragon-laptop:~/Lib/lib$ nm -g libcpputils.so | grep
> > flip | c++filt 3c20 T cpputils::flip(double)
>
> Isn't the problem that flip(double) is in namespace cpputils?
Well yes, and no. The real problem i
On Tuesday 10 March 2009 07:18:26 Ralf Wildenhues wrote:
> Undocumented (so watch out when updating Autoconf), but:
> eval "$ac_configure_args"
Didn't that get clobbered, in some not so distant past releases?
(autoconf-2.60 and 2.61 IIRC; I can't remember if it was fixed in
2.62 or not, but i
On Wednesday 15 April 2009 01:44:55 Eric Blake wrote:
> CC_FOR_BUILD is not an autoconf variable, but one that is
> typically supported by packages that need to support Canadian
> cross builds (such as gcc).
It isn't just Canadian builds that may need access to native tools,
even when building fo
On Wednesday 15 April 2009 07:06:09 Ralf Wildenhues wrote:
> > > Not all packages follow GNU Coding Standards, therefore,
> > > DESTDIR is not properly supported in a surprisingly large
> > > number of packages.
> >
> > We already enforce a level of GNUism on packages that use
> > autoconf/automake
On Wednesday 15 April 2009 17:00:53 Alfred M. Szmidt wrote:
> What is the problem with DESTDIR=C:/foo?
Nothing, if it were just `DESTDIR=C:/foo', but it isn't; the usage
is `$(DESTDIR)$(prefix)', and in a correctly configured w32 build,
$(prefix) is already C:/something, so you end up with
C:
On Wednesday 29 April 2009 17:21:58 Zainab Qureshi wrote:
> This is the error i am getting. C:/check is where i have placed
> configure.ac
>
> autoconf configure.ac
> /mingw/bin/autoconf: /c/check/C:/MinGW/bin/autom4te: No such file
> or
This looks well messed up. Since your problem is very spec
On Friday 15 May 2009 03:45:21 Alfred M. Szmidt wrote:
> How about this? I took into account Ralf's comments as well.
We're talking a generic "one-size-fits-all" INSTALL here, right?
You *cannot* unequivocally assert this...
>If you wish to install the package into a staging directory
>
On Wednesday 13 May 2009 14:22:25 Alfred M. Szmidt wrote:
> The problem is if you pass --bindir=/foo to configure, and
> then do `make install prefix=/bar', the files installed in bindir
> will be installed in /foo, and not /bar as the user might have
> exepcted; this is why passing prefix to `make
On Sunday 17 May 2009 16:13:19 Ralf Wildenhues wrote:
> Several mails in this thread have dealt with the same
> issues twice or more times. It's as if people ask questions but
> don't read answers, and that is what is very impolite towards
> other people on this mailing list.
Ralf,
I do *not* co
On Tuesday 11 August 2009 17:57:47 Dr. David Kirkby wrote:
> It STILL does not work for me, though at least it is not a syntax
> error.
>
> This is what I have in configure.ac
>
> minimum_perl_version="5.6.0"
So, within configure you run
perl -e 'require 5.6.0'
Try running that yourself, from
On Tuesday 11 August 2009 20:07:40 Dr. David Kirkby wrote:
> > Try running that yourself, from the shell prompt; do you see
> > what the problem is now? (Hint: you have a minor version of 8,
> > but you require a much later minor version of 600 or more --
> > it's arcane, but it seems to be how pe
On Wednesday 09 September 2009 18:12:02 Ralf Wildenhues wrote:
> And yes, it is perfectly possible to have subpackages that do not
> use Automake, or do not use Autoconf either. Their configure
> scripts merely have to conform to what the GNU Coding Standards
> say, and their makefiles too.
Which
On Tuesday 15 September 2009 05:31:04 Ralf Wildenhues wrote:
> > Could I add a related question:
>
> Yes, but we'd slightly prefer if you started a new thread for a
> new question.
That said, at least this much of your response is right on topic for
the original discussion...
> > is there a way
On Tuesday 03 November 2009 13:58:30 Steffen Dettmer wrote:
> interesting that this looks for "cl.exe" but not for "CL.EXE". I
> though uppercase would be correct
On MS-Windows hosts, the file system is case-insensitive, so there is
really no difference -- upper, lower or mixed case, they are the
On Friday 12 February 2010 20:55:03 David Bruce wrote:
> AC_MSG_CHECKING([for native Win32])
> case "$host" in
> *-*-mingw*)
> native_win32=yes
> ;;
> *)
> native_win32=no
> ;;
> esac
I don't know the best way to solve your principal problem, but a
better way to check for this
On Saturday 15 May 2010 18:52:10 Natalie Tasman wrote:
> I have one target which is actually a utility used during *build*
> time. Is it possible to specify one target which should *not* be
> built with the cross-compiler, but natively instead?
I faced a similar problem, when I autoconfiscated `ma
On Sunday 16 May 2010 04:41:27 NightStrike wrote:
> > I've considered creating a separate config.ac/Makefile.am for
> > this one executable, but am hoping to find a simpler solution.
>
> There's a way to do this as I recall, but I forget offhand. You'd
> really be best off asking on the automake m
On Monday 17 May 2010 20:44:31 Daniel Leidert wrote:
> > What you are attempting doesn't make much sense to me yet. The
> > whole point of i18n is that the translation files can be
> > maintained independently of the executable, and that a person
> > can install a subset of the compiled .mo files
On Monday 17 May 2010 23:55:10 Ben Pfaff wrote:
> > I have one target which is actually a utility used during
> > *build* time. Is it possible to specify one target which should
> > *not* be built with the cross-compiler, but natively instead?
>
> I find that the easiest way to deal with this probl
On Tuesday 18 May 2010 21:10:00 Eric Blake wrote:
> On 05/18/2010 05:58 AM, Keith Marshall wrote:
> > Of course, if your target is MS-Windows, it doesn't support
> > catgets or gettext OOTB, and even if you adopt one of the
> > available ports, it is likely that the user
On 03/02/12 10:20, Werner LEMBERG wrote:
>
> Thanks for the answers, Vincent and Peter!
>
>> You do as you do with whatever else you are requiring. Check if
>> #include is there, and check if you can link with some
>> API of your choice. [...]
>
> I would have expected something like this as
On 03/02/12 14:08, Keith Marshall wrote:
> I'll dig out the MINGW_AC... "standard" macro I use, and post it later.
Found it, quicker than I expected; attached.
--
Regards,
Keith.
# MINGW_AC_WIN32_NATIVE_HOST
# --
# Check if the runtime platform is a
On 27 February 2012 13:58, Eric Blake wrote:
> I'm also interested in the behavior of the following (which is what I
> have proposed that autoconf adds to all configure scripts, and will fail
> if it cannot find a shell that claims to work):
>
> test -x /; echo $?
> test -x .; echo $?
> printf '#!/
On 26/02/12 22:14, Peter Rosin wrote:
> Sorry for the late reply, but this might be relevant. Personally, I wouldn't
> classify the below as a working "test -x",
On the contrary...
> but I'm not sure what working is in this context...
>
> $ uname -a
> MINGW32_NT-6.1 PEDA-PC 1.0.17(0.48/3/2) 201
On 03/02/13 09:49, Yann Droneaud wrote:
[Moving the discussion to autoconf@gnu.org]
So to create a "valid" --build argument, I was going to use
--build=`uname -p`-`uname -s` but its producing 'x86_64-Linux' which is
not recognized by config.sub. I was surprised by the behavor and made
patches to
On 6 June 2013 12:12, Earnie Boyd wrote:
> On Thu, Jun 6, 2013 at 5:00 AM, A.P. Horst wrote:
> > Also when I just have:
> > echo "$var" | grep -Eq '^[0-9]+$'
> > echo "$?"
> -->8--
> > I am on a win7 x64 machine with MinGW 3.20 and W32API 3.17
> > sh --version
> > GNU bash, version 3.1.17(1)-relea
On 6 June 2013 12:54, Keith Marshall wrote:
> On 6 June 2013 12:12, Earnie Boyd wrote:
>
>> On Thu, Jun 6, 2013 at 5:00 AM, A.P. Horst wrote:
>> > Also when I just have:
>> > echo "$var" | grep -Eq '^[0-9]+$'
>> > ...
>>
>>
On 6 June 2013 13:41, Eric Blake wrote:
> > A more robust, (and more portable), formulation may be:
> >
> > echo $var | grep '^+\{0,1\}[0-9]\{1,\}$' > /dev/null 2>&1
>
> Why fork, when straight shell will do?
>
> case $var in
> ...
>
Agreed, avoiding the fork is a good idea, and I do often us
On 27/12/13 08:58, Guo Leaveye wrote:
> Given a short WinSock program source _testlib.c_ here:
>
> /* testlib.c */
> #include
> #include
> #include
I'm astonished that this works! If you include winsock2.h, then you
either should *not* include windows.h, or you should ensure t
What is best recommended practice, to work around the issued described
in this MinGW bug: https://sourceforge.net/p/mingw/bugs/2155/ ?
In summary: building cross-gcc, all up to stage 1 compiler build is
fine, but stage 2 cannot proceed until the host libraries are built.
The stage 1 compiler shoul
On 19/01/14 23:58, Per Bothner wrote:
> This means I have to do AC_PROG_CC unconditionally, which means
> you can't run configure unless a C compiler is available. This is
> a shame, since you only need the C compiler if --enable-kawa-frontend
> is selected.
I guess this is another facet of the i
On 26/08/14 16:18, Paul Smith wrote:
> Can't we just #define stat(_p,_b) _stat(_p,_b)? Not sure if that's
> sufficient: I'm not overly familiar with the limitations on the POSIX
> emulation functions in Windows.
That's effectively what MinGW does anyway, (although it does it through
an import lib
On 26/08/14 18:22, Eli Zaretskii wrote:
>> Date: Tue, 26 Aug 2014 08:25:38 -0700
>> From: Paul Eggert
>> Cc: Autoconf , Eric Blake ,
>> bug-make
>>
>> As far as Windows goes, NTFS file systems have 100 ns resolution, and
>> FAT file systems are the joker as they have a 2-second resolution f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/05/16 07:06, A.P. Horst wrote:
> I am using: msys-autoconf-2.68-1-msys-1.0.17
> msys-automake-1.11.1-1-msys-1.0.13
Just curious, but why? From the package description for the former:
> This msys port of autoconf has been modified
> specificall
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/05/16 09:17, A.P. Horst wrote:
> On 5/30/2016 10:07, Keith Marshall wrote:
>> On 30/05/16 07:06, A.P. Horst wrote:
>>> I am using: msys-autoconf-2.68-1-msys-1.0.17
>>> msys-automake-1.11.1-1-msys-1.0.13
>>
&g
On 13/10/16 15:24, Russell Shaw wrote:
> On 13/10/16 13:11, Luca Saiu wrote:
>
> ...
> > So, what I'm asking you is: does a clean solution exist, or compiling
> > without a runtime library is just not supported by the Autotools? It
> > sounds weird to say that for configuring you need a cross-com
On 21/08/17 07:21, Ben Pfaff wrote:
>> As the --build value can be guessed, I think that it would be annoying
>> for the user to force him to use --build in case of cross-compilation.
>> IMHO, making case 3 like case 2 with the guessed value of BUILD (as
>> I've proposed above) would make sense. Th
On 23/08/18 18:08, Earnie wrote:
> If you're using MSVC, there is no crosstool chain of software so you
> specify a fictitious --host and --build to be the same such as
> {i686,x86_64}-pc-msvc and point the environment variables to the
> binaries.
But the OP seems to want to use AC_CANONICAL_*. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/08/18 09:23, Sébastien Hinderer wrote:
> Keith Marshall (2018/08/23 20:00 +0100):
>> For --build, the output from config.guess should always be
>> suitable; for --host, it may be okay to affix an arbitrary
>> suffi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/08/18 15:42, Bob Friesenhahn wrote:
> On Sat, 25 Aug 2018, Marko Lindqvist wrote:
>
>> Indeed. When considering addition of a new macro call to
>> configure.ac it often requires a lot of digging (usually from
>> NEWS) to find out if using that m
environment.
IMO, this topic is equally deserving of discussion on an autoconf list.
Regards,
Keith.
-- Forwarded Message --
Subject: Re: [Mingw-users] MSYS_PREFIX_HACK
Date: Tue, 29 Mar 2005 16:52:39 +0100
From: Keith MARSHALL <[EMAIL PROTECTED]>
To: [EMAIL PROTECT
Earnie Boyd wrote:
> But if I change MSYS so that variable prefix is always a win32
> path value this MSYS_PREFIX_HACK would not need to be done ...
I'm curious as to how you might achieve that.
In a recently generated configure script I see the following
sequence of operations, invoked by AC_INI
On Wednesday 30 March 2005 4:02 am, Bob Friesenhahn wrote:
> On Tue, 29 Mar 2005, Brian Dessent wrote:
> > For Cygwin at least, isn't it a lot easier to just do something like
> >
> > winpath="`cygpath -w "$unixpath"`"
> >
> > than mess around parsing the output of mount and such?
>
> Yes, but it d
On Wednesday 30 March 2005 8:49 pm, Bob Friesenhahn wrote:
> > The last part of your script, i.e. the conversion of slashes to
> > backslashes, is not only unnecessary, but is actually *less* robust than
> > simply leaving the slashes as they are, (which eliminates any concern
> > over what level o
On Wednesday 30 March 2005 9:15 pm, Bob Friesenhahn wrote:
> On Wed, 30 Mar 2005, Keith Marshall wrote:
> > Well, if by the "Bourne shell" you mean MSYS' Bourne shell, (which is
> > actually `bash' masquerading as `sh'), I think you are mistaken. I
> >
>> The Windows operating system uses backslash as its native directory
>> separator. When building native Windows applications (e.g. using
>> MinGW) it seems most useful to embed path information which is
>> compatible with the operating system.
>
> A popular misconception, among Windoze developer
Bob Friesenhahn wrote:
>> ac_default_prefix=`exec 2>/dev/null;cd /usr/local;pwd -W` ||\
>>ac_default_prefix=/usr/local
>>
>> I have tested this alternative initialisation on every system
>> available to me. On SunOS 5.5.1 with `sh', `ksh' and `bash', on
>
> I am sure that this works great if
Earnie Boyd wrote:
>> 1) Variable `ac_default_prefix' is explicitly initialised,
>>as `ac_default_prefix=/usr/local'
>>
>> 2) Variable `prefix' is explicitly initialised, as
>>`prefix=NONE'
>>
>
> Relative paths are not converted so the value of prefix will be
unchanged.
>
>> 3) Command li
Stepan Kasal wrote:
> Keith Marshall wrote:
>> ac_default_prefix=`exec 2>/dev/null;cd /usr/local&&pwd -W` ||\
>> ac_default_prefix=/usr/local
>
> This is a possible solution, but I'd like to propose something simpler:
>
> AC_INIT reads file config.s
Nicolas Haller wrote:
>>> If I understand, Makefile.in are generated with informations enclosed
in
>>> Makefile.am. But I have no Makefile.am in subdirs of src/. I have only
>>> sources files (.hh and .cc), and nothing to do with these (but object
>>> file to build the program define in src/Makefi
On Sunday 01 May 2005 10:55 pm, Jeff Conrad wrote:
> > You could possibly extend this, to override the default initialisation
> > for `ac_ext', and to supply your preferred `CC', `CFLAGS' and `CXXFLAGS'
> > initialisations.
>
> This indeed is a useful suggestion; alas, it seems to work for everythi
On Friday 06 May 2005 8:09 pm, Zvezdan Petkovic wrote:
> Obviously only gmake recognizes .cpp as a C++ file on a Unix system.
> With older version of gmake on a different Unix machine .cpp has not
> been recognized.
This is precisely the reason why I suggested a slightly more sophisticated
patch,
On Friday 06 May 2005 9:54 pm, Paul Eggert wrote:
> Keith Marshall <[EMAIL PROTECTED]> writes:
> > On Friday 06 May 2005 8:09 pm, Zvezdan Petkovic wrote:
> >> Obviously only gmake recognizes .cpp as a C++ file on a Unix system.
> >> With older version of gmake on
On Saturday 14 May 2005 4:10 pm, Alexandre Duret-Lutz wrote:
> >>> "Stepan" == Stepan Kasal <[EMAIL PROTECTED]> writes:
>
> [...]
>
> Stepan> I suggest that Automake automatically sets these make variables:
>
> Stepan> abs_srcdir
> Stepan> abs_builddir
> Stepan> abs_top_srcdir
> Stepan> abs_to
Ok... I know RFC technically means "Request for Comments", but here I'm
abusing it to mean "Request for Clarification" :-)
On another mailing list ...
https://sourceforge.net/mailarchive/message.php?msg_id=11882330
I saw this response to a suggestion that, IMO, config.h as generated by
an aut
Stepan Kasal wrote:
> On Fri, May 27, 2005 at 09:49:54AM +0100, Keith MARSHALL wrote:
>>> The book I just got on 'autoconf' mentions that editing 'config.h'
>>> is one of the things that is expected. It explains the format of
>>> the file which i
Stepan Kasal wrote:
> It's hard to tell whether a macro calls AC_REQUIRE. (It can call it
> indirectly.)
>
> A real fix will be to use shell functions to reimplement AC_REQUIRE,
> in autoconf-3.
Are you now saying that shell functions are safe to use in a portable
fashion? That would contradict
Stepan Kasal wrote, quoting me:
> On Fri, May 27, 2005 at 01:38:28PM +0100, Keith MARSHALL wrote:
>>> #! /usr/bin/perl
>>>
>>> If you omit the space before the path, then 4.2BSD based systems
>>> (such as DYNIX) will ignore the line, because they i
Bob Friesenhahn wrote, quoting me:
>> BTW, why does the "#undef HAVE_SOMEHEADER_H" in config.h.in get
>> wrapped in comment marks, when it is copied into config.h? Does it
>> not make more sense to forcibly ensure that HAVE_SOMEHEADER_H is not
>> defined, if configure has determined that someheade
Bob Friesenhahn wrote, quoting me:
>> Yes, I see the logic of that. But, if configure has already
>> determined that the header file is not present, or at least not
>> usable, why would any user realistically want to do that?
>
> The autoconf philosophy is that the user (person who builds the
> so
> Hello,
gnulib is an existing centralised repository, with implementations
under various licenses, but mostly they are GPL or LGPL.
>>>
>>> Maybe there could be a note about that in the autoconf manual ?
>>
>> standards.texi, which is distributed with Autoconf, mentiones it.
>>
>> But
On Tuesday 12 July 2005 5:11 pm, Paul Eggert wrote:
> "Dieter Theuerkauf" <[EMAIL PROTECTED]> writes:
> > make: sh: Command not found
>
> It looks like you need to install a shell. "sh" is the name of the
> POSIX (or Bourne) shell. Bash is a good implementation:
>
> http://www.gnu.org/software/ba
On Tuesday 12 July 2005 10:29 pm, Keith Marshall wrote:
> Dieter, make sure you really are running your configure && make etc. in the
> msys shell, and not in a cmd.exe (DOS) box. Easier still, just grab a
> ready made autoconf 2.59 kit for Win32/MSYS from the MinGW download
On Saturday 16 July 2005 12:24 pm, Chris Coleman wrote:
> WANT_BOOST_MAJOR=`echo $boost_min_version | $AWK -F. '{print $1}'`
> echo $WANT_BOOST_MAJOR
>
> $1 => 1.320
> $2 => 1.32.0
> $3 => gives the below error:
> awk: syntax error at source line 1
> context is
> {print >>> { <<<
> awk: i
On Sunday 17 July 2005 3:19 am, Paul Eggert wrote:
> Stepan Kasal <[EMAIL PROTECTED]> writes:
> > I noticed that Paul Eggert uses '{print $ 1}'.
>
> Yes, I found that to be by far the best solution, as '$ 1' makes it
> clear that it's the Awk '$1' rather than the M4 '$1'.
>
> The $[1], [$]1, and $[
Hello,
I would like to implement a configure option which would have the effect of
AC_DEFUN([MY_LANGUAGE_SET],
[AC_ARG_WITH([languages],
AS_HELP_STRING([--with-languages=LIST],
[install language files in LIST, a comma separated subset of '$1']),
[languages=$withval],
[languages=en])])
MY_LANGUAG
On Sunday 31 July 2005 9:32 pm, Harlan Stenn wrote:
> What about using GNU AutoGen and having it spit out an updated
> configure.ac whenever your template changes?
I considered this, but it brings to mind associations of sledge hammers and
cracking nuts, to say nothing of yet another complex tool
On Sunday 31 July 2005 10:49 pm, Andreas Schwab wrote:
> > MY_LANGUAGE_SET([`cd lang; echo ?? | tr " " ,`])
> >
> > and have the result of the command substitution
> >
> > `cd lang; echo ?? | tr " " ,`
> >
> > appear in the `configure --help' output.
>
> This won't do the right thing if configur
>> > Given these limitations, can anyone suggest a better mechanism for
>> > achieving this objective?
>>
>> Use esyscmd to interpolate the output of the command at configure
creation
>> time.
>
> But does that really offer any advantage over using a shell script to do
the
> same thing? It stil
Matthias Langer wrote:
> I'm trying to to the following in my configure.ac:
>
> VTK_LIBS=$vtk_lib_path
> VTK_LIBS+="-lvtkFiltering -lvtkfreetype -lvtkftgl -lvtkGraphics
> -lvtkHybrid" \
>"-lvtkImaging -lvtkIO -lvtkRendering"
>
> However, when i run configure, i get
> ...: V
On Wednesday 28 September 2005 10:04 am, Andreas Schwab wrote:
> Akim Demaille <[EMAIL PROTECTED]> writes:
> > if (local foo) >/dev/null 2>&1; then :; else
> > local () { true; }
> > fi
>
> Note that local is only valid in function context, so this will always
> produce a failure.
For pedant po
Jason Gerfen wrote:
> Here is the bit I am adding, but when I run aclocal, autoconf,
> automake the option does not appear in the ./configure --help
> menu, nor does it link against the -lldap libs. Any help,
> pointers, tips, tutorials are appreciated.
>
> [definition of PKRB5_CHECK_LDAP snipped]
> You were right, I added it to the configure.in and it is now
> displaying my option to --enable-ldap, but when specified to
> the ./configure it is not linking. Am I missing something
> futher? I really apologize for being a newb to this but any
> help is appreciated.
No need to apologise -- w
Jason Gerfen wrote:
> Yeah, I actually went through and added the appropriate syntax to
> each of the macro's which has gotte rid of warnings when running
> 'aclocal'. When I run 'make' after running
> './configure --enable-ldap'
> I do not see anything specifying the '-lldap' linking.
Does you
Ralf Wildenhues wrote:
> Can I assume AC_FOREACH is a stable, public interface?
> Should I try to write documentation for it?
> If not: is there a similar macro I can assume to be public and stable?
Indeed, I've wondered about this too.
I've seen it used, (in groff's aclocal.m4), and have even us
Oops. Forgot that GNU's list mailers don't set the Reply-to header
properly, (can this not be fixed?), and only replied privately to
Stepan.
- Forwarded by Keith MARSHALL/LOR/GB/RM/Corp on 20-10-2005 11:44 AM
-----
Keith MARSHALL
20-10-2005 11:20 AM
To: stepan kas
Stepan Kasal wrote, quoting me:
>> I *like* autoconf, but, if I have one harsh criticism, it is that
>> perfectly good macro names are deprecated much too frequently.
>
> Yes, I miss AC_TRY_COMPILE and friends. Unfortunately, since the new
> interface is (subtly) different, it was necessary to fi
On Friday 21 October 2005 10:42 pm, Alexandre Duret-Lutz wrote:
> >>> "KM" == Keith MARSHALL <[EMAIL PROTECTED]> writes:
>
> KM> When I write my configure.ac, aclocal.m4, or acinclude.m4, *every*
> KM> macro I use is, from my perspective, an *auto
[In response to an aside comment, appearing in the "AC_FOREACH Public? thread]
On Thursday 20 October 2005 1:31 pm, Stepan Kasal wrote:
> On Thu, Oct 20, 2005 at 11:48:20AM +0100, Keith MARSHALL wrote:
> > Oops. Forgot that GNU's list mailers don't set the Reply-to header
On Saturday 22 October 2005 10:08 am, Allan Clark wrote:
> You might want to consider switching to elm, mutt, or a Mozilla-based
> client (if you're a graphical guy); they have these features, and are
> fairly well-tested.
I don't have any option to do this -- I am obliged by Company policy to use
>> But "Reply-to-All" is *not* the most appropriate solution --
>> it's what I used here, so *you* can have *two* copies of this
>> message.
>
> Personally, I configure my mailreader to discard duplicates.
Great, if you aren't compelled, by your corporate IT department,
to use an unconfigurable le
Allan Clark wrote, quoting me:
>> But "Reply-to-All" is *not* the most appropriate solution -- it's what
>> I used here, so *you* can have *two* copies of this message.
>
> great. I've got two eyes. These duplicates are statistical noise in
> the world of spam...
And I'm sure they are extreme
Ralf Wildenhues wrote, quoting me:
>> Why would anyone want to do so anyway? If I want to write a shell
>> script, other than as a configure script, it's *much* more logical
>> and convenient for me to just write directly as such, in the shell's
>> own native language.
>
> Those who don't use M4SH
Stepan Kasal wrote:
> I think that the parametr to compile should look like
>some/path/main.c
> which becomes cfile, and then cofile is assigned as...
Just guessing, but with cl.exe being Bill's C compiler, it
probably doesn't understand `some/path/main.c' as a path name;
(it will
Stepan Kasal wrote:
> is it true that
>
>a= ; for f in $a; do ... done
>
> is not interpreted correctly by some shells?
There was some discussion on a related problem, on one of the
MinGW fora, a couple of months back. In a *Makefile*
LIST =
some-target:
for i in ${LIST}; \
Ralf Wildenhues wrote, quoting me:
>>> Those who don't use M4SH_INIT are doomed to reinvent it, painfully.
>>
>> Oh yeah? And M4SH_INIT is so well documented, that everyone will
>> rush to use it!
>
> I already agreed with you that the documentation is bad or not present
> in some cases, and t
Stepan Kasal wrote:
> 3) There is an MSYS build of bash. Though MinGW/MSYS is not ready
> to run Autoconf, you can use it to unpack a tarball and run ./configure
> there.
I don't know where you get this idea from. I have been using Autoconf
2.59 in the MSYS environment for at least nine months n
Dan Manthey wrote:
> My Windows environment doesn't have 8.3 issues, so I can't guess
> whether there's any need to support 8.3 filenames under MSYS.
There isn't. MSYS requires 32-bit Windoze; *all* 32-bit Windoze
implementations support long file names.
Regards,
Keith.
___
> As for the argument that ``The requirement to support 8.3 file names
> disappeared with the demise of MS-DOS'' when Windows 95 was
> introduced, it is IMNSHO is ridiculous.
Ok. I accept that `disappeared' and `demise' were probably poorly
chosen words -- what I really meant was `diminished' and
On Tuesday 25 October 2005 3:45 pm, Brian wrote:
> Great thanks for the tips. I see its a bit chicken and egg, but is there a
> reason config.h couldn't just define HAVE_CONFIG_H?
Because your source file is expected to use logic like this:--
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
Stepan Kasal wrote:
> And I supposed the OP uses automake since it's more probable
> than the contrary.
Methinks that you presume too much. I routinely use Autoconf,
but I do not, and will not, use Automake.
Regards,
Keith.
___
Autoconf mailing list
On Thursday 01 December 2005 6:40 am, Roesner Thomas wrote:
> thank you for the replie, "make DESTDIR=`pwd` install" works fine, but i´d
> like to omit the naming of the installpath in all commands. I´d prefer
> setting it within the configure.in or Makefile.am.
You _could_ just say `prefix=""', i
A further thought:
On Thursday 01 December 2005 1:54 pm, I wrote:
> On Thursday 01 December 2005 6:40 am, Roesner Thomas wrote:
> > thank you for the replie, "make DESTDIR=`pwd` install" works fine, but
> > i´d like to omit the naming of the installpath in all commands. I´d
> > prefer setting it w
1 - 100 of 227 matches
Mail list logo
