You know, I've recently finished reading the manuals for m4, libtool,
autoconf, and automake. After 1000 pages of reading, I was frustrated to
walk away knowing very little more than I started with. I believe this
is primarily due to the lack of examples and background context in the
explanations
/disable them conditionally, as maintainer/programmer configuration
dictates.
My question: Anyone know of a good idiom for managing optimization flags -
including disabling the obligatory -O2 placed in CFLAGS by AC_PROG_CC?
Thanks,
John
-
John Calcote ([EMAIL PROTECTED])
Sr. Software
configuration file is set to allow the user to override
all of these options if they use CFLAGS on the command line of either
configure, or make.
John
Brian Dessent [EMAIL PROTECTED] 2/6/2006 5:25:04 pm
John Calcote wrote:
Generally, when I build with the DEBUG macro defined, it's because I
want
:14AM +0100, Andreas Schwab wrote:
John Calcote [EMAIL PROTECTED] writes:
My question: Anyone know of a good idiom for managing optimization
flags -
including disabling the obligatory -O2 placed in CFLAGS by
AC_PROG_CC?
.../configure CFLAGS=-g
Just out of curiosity, is this different than
When you override CFLAGS on the configure command line, you give
configure the opportunity to add more flags to the CFLAGS variable that
are then passed on to make. On the other hand, when you modify CFLAGS on
the make command line, you are overriding all settings provided to the
Makefile by the
configuration file is set to allow the user to override
all of these options if they use CFLAGS on the command line of either
configure, or make.
John
Brian Dessent [EMAIL PROTECTED] 2/6/2006 5:25:04 pm
John Calcote wrote:
Generally, when I build with the DEBUG macro defined, it's because I
want
, or
--with-full-optimization, etc.
John
Andreas Schwab [EMAIL PROTECTED] 2/7/2006 11:34:30 am
John Calcote [EMAIL PROTECTED] writes:
When you override CFLAGS on the configure command line, you give
configure the opportunity to add more flags to the CFLAGS variable that
are then passed on to make
In the autoconf manual in Chapter 3, page 5 it states:
... If you write your own feature tests to supplement those that come
with Autoconf, you might also write files called ‘aclocal.m4’ and
‘acsite.m4’...
I understand acsite.m4, but I thought aclocal.m4 was *generated* by the
aclocal
Peter O'Gorman wrote:
Tim Dennis wrote:
Hi John,
In the autoconf manual in Chapter 3, page 5 it states:
... If you write your own feature tests to supplement those that come
with Autoconf, you might also write files called ‘aclocal.m4’ and
‘acsite.m4’...
It all depends on if you are
Andreas Schwab wrote:
John Calcote [EMAIL PROTECTED] writes:
The autoconf manual suggests that you should WRITE an aclocal.m4
if you want to add project-specific tests. If you write one, will the
aclocal script append to the one you wrote?
If you use aclocal you write aclocal.m4
Sorry for the list spam, but I thought people on this list might be
interested in a new book on using the GNU Autotools, called
Autotools: A Practitioner's Guide to Autoconf, Automake and Libtool
You can find it at free software magazine (freesoftwaremagazine.com):
On Tue, Mar 25, 2008 at 12:18 PM, Ralf Wildenhues
[EMAIL PROTECTED] wrote:
No problem, but could we continue this discussion on one list only,
say, the autoconf one, for lack of a better choice? Thanks.
Reply-To and Mail-Followup-To set.
Absolutely - autoconf it is.
Here's a 3-second
Ralf,
Excellent feedback - thank you.
When do you think 2.62 will be released? I'll get the repository code
if I need to work on that chapter before that date, but I'm just
curious. :)
John
On Tue, Mar 25, 2008 at 3:37 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Hello John,
here's a
Hi Eric, (et.al.),
I've run into a possible bug in the Autoconf (2.62, and previous)
package while I've been playing with it lately.
1. The manual indicates in sec 5.2, pg 39, bottom of the page (Feb 08
2.61 version) that autoconf ships with a version of install-sh that
you can use if you wish.
Eric,
Eric Blake wrote:
According to John Calcote on 4/10/2008 3:00 PM:
|
| you can use if you wish. I believe this to be an inaccurate statement,
| as no install-sh script actually gets installed with the autoconf
| package (at least not lately).
It's there, as autoconf-2.62/build-aux/install
Hi Eric list,
According to the doc (Section 5.9.1 of the GNU Autoconf manual):
AC_TYPE_UINT8_T [Macro]
If 'stdint.h' or 'inttypes.h' defines the
type uint8_t, define HAVE_UINT8_T. Otherwise,
define uint8_t to an unsigned integer type
that is exactly 8 bits wide, if such a type
exists.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Geez, you'd think I'd have learned by now! :) This won't happen again,
as I've just downloaded the April versions of the GNU docs. Sorry for
the trouble.
- --john
Ralf Wildenhues wrote:
Hello John,
* John Calcote wrote on Mon, Apr 21, 2008 at 11
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Post wrote:
In my configure.ac, I have added:
# Check for package options
AC_ARG_ENABLE(unsafe, [ --enable-unsafe enable unsafe operation
[[default=no]]],[
if test $enableval = no; then
ac_enable_unsafe=no
else
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aaragon,
aaragon wrote:
Hi everyone,
A project of mine uses two autotools projects, each of which creates a
config.h file where there are a bunch of #define statements. Well, when I
compile I see several warning messages telling me that some of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Friesenhahn wrote:
On Tue, 13 May 2008, John Calcote wrote:
But this is very common mistake. It comes from carelessness about which
header files are considered part of the public interface, and which ones
should be kept private. The generated
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Michaux wrote:
AC_SUBST(XJS_LOAD_PATH)
if [[ -z ${XJS_LOAD_PATH} ]]
then
XJS_LOAD_PATH=.:~/lib/xjs:/usr/local/lib/xjs:/usr/lib/xjs:/lib/xjs
fi
I have a feeling this might not be the normal way to do this.
For one thing, the double
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm trying to autoconfiscate an existing project using autoscan. The
configure.scan file (which I renamed to configure.ac) seems to work fine
after the usual tweaking -- project name, version, bug-report, library
functions, AC_CONFIG_FILES, etc.
When
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi (adding the libtool mailing list),
Richard Ash wrote:
$ autoreconf -i
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: You should add the contents of the following files to
`aclocal.m4':
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm autoconfiscating an existing project, and have come up against a
design decision. I hope I can get some advice from the list members:
My project is really three projects--two database management systems,
each built on top of a common portability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
Hello,
* John Calcote wrote on Mon, Jun 09, 2008 at 05:32:23PM CEST:
Richard Ash wrote:
$ autoreconf -i
libtoolize: You should add the contents of the following files to
`aclocal.m4':
libtoolize: `/usr/local/share
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
3. I've considered creating a configure.ac at the projects level, and
making all three components sub-projects.
That's the way to go.
This would alleviate the
problem mentioned with point 2 above, but I don't think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm interested in finding out more about the pkgconfig project --
specifically, how well it's received by the Autotools community.
As is usual in the open source world, most of the information on this
project assumes you already know a lot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm building a configure.ac file that would like to provide some
platform-specific options as command-line options.
For example, on Solaris SPARC hosts, you can target sparc-generic code,
if you wish, but it makes no sense to even see an option,
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
I've also thought about the possibility of adding some solaris only
text to the help text for the option.
Not really possible either. How would you know that with
./configure --help
Sorry - poorly worded question.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there a community-approved method for determining in configure.ac
whether or not you're building (targeting) 64-bit code?
Seems that given the recent increase in popularity of 64-bit hardware,
it might be a good idea to add a standard Autoconf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
Hi John,
* John Calcote wrote on Mon, Jun 23, 2008 at 08:26:09PM CEST:
Is there a community-approved method for determining in configure.ac
whether or not you're building (targeting) 64-bit code?
What is 64-bit code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
* John Calcote wrote on Mon, Jun 23, 2008 at 10:02:30PM CEST:
3. The code was particular to MS Windows. In these situations, it's
pretty clear that MS doesn't care about portable code.
But what about w64? Haven't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Jonas wrote:
src/
foo.cc
bar.cc
main.cc
Makefile.am
tests/
foo_test.cc
bar_test.cc
testrunner.cc
Makefile.am
What I'd like to be able to do is build testrunner from testrunner.o,
foo_test.o, bar_test.o, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
For what little it's worth, I'd write that as
src/Makefile.am:
noinst_LIBRARIES = libtest.a
libtest_a_SOURCES = foo.cc bar.cc
bin_PROGRAMS = myprog
myprog_SOURCES = main.cc
myprog_LDADD = libtest.a
tests/Makefile.am:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've written a treatise on this subject in my autotools book:
http://www.freesoftwaremagazine.com/books/agaal/catalog_of_reusable_solutions
The first sub-topic is the one you want - Never expose config.h in a
public interface.
- --john
Ralf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Friesenhahn wrote:
On Thu, 21 Aug 2008, Thomas Dickey wrote:
If it's _his_ source code (and assuming that _he_ licensed it GPL), he
can distribute whatever set of files he chooses. The restriction
applies for files that he gets from someone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yavor Doganov wrote:
В Fri, 22 Aug 2008 11:21:04 +0800, Tim Post написа:
The GPL requires only that you make the source code available with all
files needed to complete the build. So, in essence, you could exclude
the things needed to rebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Friesenhahn wrote:
On Fri, 22 Aug 2008, John Calcote wrote:
As someone has already mentioned, the rules of the GPL *ONLY* apply to
non-originators. The purpose of the GPL is to protect the rights of the
originator. The originator of software
You may wish to check out my book on Autotools, hosted by Free Software
Magazine. In there, I make several references to doxygen, and use code
snippets to implement doxygen targets within the sample projects and
examples provided in the book.
Stefano D'Angelo wrote:
2008/10/3 Stefano D'Angelo [EMAIL PROTECTED]:
2008/10/2 John Calcote [EMAIL PROTECTED]:
You may wish to check out my book on Autotools, hosted by Free Software
Magazine. In there, I make several references to doxygen, and use code
snippets to implement
Ralf,
The trouble with your approach is that it doesn't solve the original
poster's issue. The issue was that when such variables are expanded into
config.h using the regular AC_DEFINE mechanism, environment variables
don't get expanded in the variable substitution:
--- snip ---
prefix=
Aragon,
As you've already figured out, AC_CHECK_LIB was designed for C linkage. That
means that you'd need to name your function exactly as it is exported by
your library - eg., ZN8cpputils4flipEd (minus the leading underscore
character) - in order to trick the macro into finding it. This is a
Oh, and one more point about that suggestion I sent you about using the
mangled name (before someone flames me on it) - the mangling scheme is
compiler/vendor specific. Thus, this hack will only work if you can always
be assured that you'll be using g++, and not some other vendor's C++
compiler.
The AC_CHECK_LIB macro doesn't even attempt to call the specified function.
In fact, it merely attempts to import it as if it were a global data item in
the library. The check code boils down to something like this:
int main() {
#ifdef __cplusplus
extern C
#endif
char your_function_here;
return
Alejandro,
Dig out the M4 manual and read the first chapter. M4 is much like the C
preprocessor in many ways. In C, if you put a space between a macro name
and the opening paren in the definition, the preprocessor won't
recognize the macro as a function-like macro either. How do you handle
Quick question for someone who knows...
Anyone out there know why the INSTALL_DATA variable resolves to
$(INSTALL) -m 0644, but the INSTALL_SCRIPT and INSTALL_PROGRAM variables
only resolve to $INSTALL, and not $INSTALL -m 0755?
Thanks,
John
___
On 4/20/2009 6:15 PM, Russ Allbery wrote:
John Calcotejohn.calc...@gmail.com writes:
Quick question for someone who knows...
Anyone out there know why the INSTALL_DATA variable resolves to
$(INSTALL) -m 0644, but the INSTALL_SCRIPT and INSTALL_PROGRAM
variables only resolve to $INSTALL,
Ed,
On 4/21/2009 7:45 AM, Ed Hartnett wrote:
Howdy all!
I want to put a line break in the error message so that I don't have
such a long line in my configure.ac file. But if I do this:
AC_MSG_ERROR([NetCDF-4 requires HDF5, but hdf5.h cannot be found. Try
using \
the --with-hdf5
On 4/22/2009 2:52 AM, Nina Nordstrom wrote:
Hello,
I have an autoconf problem I am trying to solve: Basically I need to add new
macros and use them in configure.ac... specifically, I would like to add a
macro called AX_GCC_ARCHFLAG found in the autoconf macro archive somewhere
in my package and
Hi David,
On 4/22/2009 11:52 AM, David Bruce wrote:
Hi,
I'm about to start modifying my program (Tux Typing) so as to allow
creation of custom word lists. The gist is that I need to have
modifiable files that are visible to all users. I have been told by
knowledgable people that the
On 4/22/2009 8:42 PM, Eric Blake wrote:
gcc has a compile farm, http://gcc.gnu.org/wiki/CompileFarm
Eric,
Thanks for this tip! SourceForge.net used to have one, but they killed
it a few years ago - I imagine it was too much effort to maintain. Too
bad, because you have no other way of
Hi Christophe-Marie,
On 4/28/2009 10:32 AM, Christophe-Marie Duquesne wrote:
I've read it was deprecated to deliver the file config.h generated by
autoheader (or whatever name you give it) in a project (see (1)).
I think there are several issues here that are confused.
config.h is
Tommy,
On 4/28/2009 2:16 PM, Tommy Nordgren wrote:
I need to check for scripting languages (ruby, perl , python 2.x ,
python 3.0) and generating a script file
depending on what's available.
I do this in the following way
if ruby is available:
cp collect.rb collect chmod +x collect
if perl is
On 4/29/2009 9:05 AM, Zainab Qureshi wrote:
Hi,I am having problems while installing GNURadio on windows xp. The problem
lies with autoconf. In config.log i get the following error
AUTOCONF='${SHELL} /c/gnuradio-3.1.3/missing --run autoconf'
AUTOHEADER='${SHELL} /c/gnuradio-3.1.3/missing --run
Hi Peter and Christophe-Marie,
On 7/16/2009 9:28 AM, Christophe-Marie Duquesne wrote:
I wonder if there are actually a lot of programmers who used the
autotools in IDEs and did not came back to classic text editors.
In my experience, there is little need for an IDE when writing C/C++
Hi Willem,
As you may have discovered by now, the algorithm used by Automake to
reference the autotools-installed utility scripts pre-pends the
functional inverse of the $(srcdir) path to the utility program name as
it's referenced. Thus, if you had a project, test with the following
Hello Abhinav,
On 8/1/2009 9:04 AM, Abhinav Singh wrote:
Hi,
This is my first time with autotools and I tried following:
http://www.gnu.org/software/libtool/manual/automake/Creating-amhello.html#Creating-amhello
to get started.
However when I issue the:
*$bash: autoreconf --install*
I get
Hi Bob,
You really shouldn't be so facetious. :) Even though everyone uses M$
tools, no one really wants to admit what you just stated.
John
On 8/10/2009 11:15 AM, Bob Friesenhahn wrote:
On Mon, 10 Aug 2009, Andrew W. Nosenko wrote:
'-I', '-l' and '-L' are standard flags supported by any
Hi Mick,
Your Automake syntax is correct, if you're trying to install a
pre-existing data file called nuchimp.xml into the /usr/local/share
(default $(datadir)) directory. The error you're getting indicates that
make can't fine the file nuchimp.xml. Are you sure it exists in the same
I'm wondering about best practices for checking for programs like the
javac compiler. For instance, I currently have a line in my project's
configure.ac file that looks like this:
AC_CHECK_PROGS([JAVAC], [gcj -C -ftarget=1.4 -fsource=1.4 guavac
-target 1.4 -source 1.4 jikes -target 1.4
Hi Ralf,
Hey, thanks for the response.
On 8/22/2009 1:59 AM, Ralf Wildenhues wrote:
Hello John,
* John Calcote wrote on Fri, Aug 21, 2009 at 02:44:03AM CEST:
I'm wondering about best practices for checking for programs like
the javac compiler. For instance, I currently have a line in my
I've got a friend at work that's experiencing this problem while
building an apache distribution:
...
utilities/agctl/Makefile.am:16: compiling `agctl.c' with per-target
flags requires `AM_PROG_CC_C_O' in `configure.in'
Makefile.am: installing `./INSTALL'
Running autoconf ...
Running
Hi David,
On 9/19/2009 4:43 PM, David Bruce wrote:
I have a project with all the source files in a src directory just
below trunk, which is where the top level configure.ac and Makefile.am
live. When I run configure, config.h is created at build/config.h.
If I run configure from within trunk,
Hi Andrew,
On 10/23/2009 5:34 PM, Andrew W. Nosenko wrote:
On Fri, Oct 23, 2009 at 00:50, Alfred M. Szmidta...@gnu.org wrote:
The way is to simply not use pkg-config, and use AC_CHECK_* functions
to find what is needed; and let the user specify where/what, using
*FLAGS.
Can I ask
Matěj,
On 10/25/2009 8:05 AM, Matěj Týč wrote:
There is one big issue with AC_SEARCH_LIBS: If you use a different
calling convention than cdecl (like stdcall, but I don't know, they've
just told me), you will get unresolved symbols if you try to link
without a proper include file (or something
On 10/27/2009 11:44 AM, Matěj Týč wrote:
On Mon, 2009-10-26 at 21:34 +0100, Ralf Wildenhues wrote:
3) The pressing issue that Matěj complained about was when configure
fails to detect all libraries, because all of them have a different
calling convention. Right?
The situation that
Hi Ralf,
On 10/27/2009 3:41 PM, Ralf Wildenhues wrote:
In the current scheme, AC_CHECK_LIB only tries to*link* a function
call, not to actually run the linked code. There are two aspects here
to consider:
1) This might not be a sharp enough test to decide which calling
convention is used
Hi David,
On 1/21/2010 4:38 PM, David Byron wrote:
Let's say I have a header file named foo.h that contains:
#define FOO an_interesting_value
(I think) I'm looking for a macro like this:
AC_GET_VALUE([foo.h],[FOO])
that populates ac_cv_value_of_FOO with an_interesting_value
This is
On 3/7/2010 11:53 AM, Bob Friesenhahn wrote:
On Sun, 7 Mar 2010, Carsten Heinrici wrote:
but: if there is this golden rule to always have them included first,
there should be no harm if they would include inclusion guards.
what am I missing here?
There may be several config.h files, each of
On 3/7/2010 2:40 PM, Tim Rice wrote:
On Sun, 7 Mar 2010, John Calcote wrote:
On 3/7/2010 11:53 AM, Bob Friesenhahn wrote:
[...]
There may be several config.h files, each of which has somewhat different
content. Bing!
So what would be wrong with generating an include
On 3/7/2010 4:38 PM, Carsten Heinrici wrote:
but: if there is this golden rule to always have them included first,
there should be no harm if they would include inclusion guards.
what am I missing here?
There may be several config.h files, each of which has somewhat different
content.
On 3/10/2010 3:19 PM, TJ Yang wrote:
I still don't see why you think this is a good thing. This violates the
GNU Coding Standards. Most developers are already quite familiar with
the concept of './configure --help' if they want details, without having
to be told that with a no-argument run;
TJ,
On 3/20/2010 7:56 PM, TJ Yang wrote:
According to
http://www.gnu.org/software/hello/manual/autoconf/Initializing-configure.html
I can do a AC_INIT(hello,1.0,[t...@test.com],[tarname],[http://www.test.com])
and expect to have PACKAGE* veritable set accordingly, see Makefile below.
But I
Hi Monty,
On 6/10/2010 11:42 AM, Monty Taylor wrote:
Hey all,
Potentially odd question...
How would I accomplish something like what's in the subject? I have a
source file that wants to be built before other files - so including it
in BUILT_SOURCES does the right thing, but I do _not_ want
On 6/30/2010 3:48 AM, Andrew W. Nosenko wrote:
Excuse me, but why just don't
#include inttypes.h
and use int32_t and uint32_t declared there?
If you want to deal with some heavy non-posix, or just too old system, then
AC_TYPE_INT32_T
autoconf macro (and like) may help you.
Hi Sammy,
On 7/8/2010 10:48 PM, Sam Silla wrote:
Hello,
I would like to create an array of values to use in configure.ac and am
unsure what the best way to accomplish this is. I was wondering if Autoconf
comes with native support for constructing and iterating through arrays.
You have to
Hi all.
Just a quick note to let you all know that my Autotools book has been
published (finally!) by No Starch Press:
http://nostarch.com/autotools.htm
I apologize in advance for the apparent self-promoting tone of this
message but I know there are folks out there interested in hearing
Hi Ralf,
On 7/31/2010 9:23 AM, Ralf Wildenhues wrote:
Hello,
several good suggestions for improving Autoconf were made at GHM.
Two of them are a bit related, so I'm sending them in one message.
1) Autoconf should have macros for delayed error reporting.
Example: wget foo-1.tar.gz, run
Hi all,
I ran into an interesting issue today. Hoping some of you have some
insight for me. I needed to use a later addition to the pthreads spec -
pthread_mutexaddr_settype (in order to initialize a recursive mutex). To
use this function, you need to define __USE_UNIX98 before including
On 8/23/2010 12:01 PM, Paul Eggert wrote:
On 08/23/10 10:28, John Calcote wrote:
What is the correct approach for this situation? Should I simply define
__USE_UNIX98 in my source code
No, because that symbol is private to glibc. I wouldn't mess with it.
Instead, use Autoconf's
On 01/11/2011 04:31 AM, Russell Shaw wrote:
Hi,
On debian, there is /usr/bin/bison, and
/usr/bin/bison.yacc just does:
exec '/usr/bin/bison' -y $@
How can i get autoconf to use bison?
The problem with yacc is that you can't rename
the output files and always get: y.tab.h y.tab.c
Is
Mike,
On 01/19/2011 11:43 PM, Ralf Wildenhues wrote:
* Mike Gran wrote on Wed, Jan 19, 2011 at 06:26:24PM CET:
pkgsitedir=$datadir/$PACKAGE_NAME
AC_MSG_WARN([]
[The modules will be installed in ${pkgsitedir}.])
When I run it, I get the text
configure: WARNING:
On 03/20/2011 12:43 PM, Paul Elliott wrote:
I have the auto* tools setup to build a library. What I want is an rpm source
package and a debian source package. autoconfig.ac has the dependancy
information. Are there any automated tools to go from the autotools setup to
the source package?
-Original Message-
From: autoconf-bounces+john.calcote=gmail@gnu.org
[mailto:autoconf-bounces+john.calcote=gmail@gnu.org] On Behalf Of
Shawn H Corey
Sent: Thursday, September 04, 2014 4:05 PM
To: autoconf
Subject: Re: A Closer Look at GNU AutoTools
...
That's because you
On 09/04/2014 11:40 PM, John Calcote wrote:
If you're looking for a tutorial that walks you through the small set
of tasks that you personally need to perform, you're unlikely to find
one unless you write it.
As I see it, this is a clear indicator that the manual is sub-par and
doesn't
The division open source vs commercial is wrong. you certainly know
that
open source is a development model, it can be and it is used both in
commercial and non-commercial projects.
I'm sorry - you're absolutely right Ineiev - please forgive my oversight. I
made a fatal mistake using open
I honestly don't get why you have a problem with this attitude in open
source software.
This is not an open source software problem. It's your attitude problem,
that
is being reflected in single open source software project.
There is nothing in the source code that forces people to
Use --sysconfdir=/etc when you use --prefix=/usr.
Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone
Original message
From: Roman Neuhauser neuhau...@sigpipe.cz
Date:03/19/2015 3:49 PM (GMT-07:00)
To: autoconf@gnu.org
Cc:
Subject: sysconfdir
sysconfdir is
Hello Ying,
You're probably running a linux distribution. If it's debian based
(such as Ubuntu), then run the following command from a command prompt
(as root):
# apt-get install autoconf
If it's a redhat-based distribution such as RHEL, SuSE, or Fedora, run
this command:
# yum install
On Tue, May 29, 2018 at 7:34 PM, Nick Bowler wrote:
> On 2018-05-29, John Calcote wrote:
> > I'm trying to create a test using autotest that compares the stdout of my
>
> So, we can do (totally untested)
>
> AT_INIT
> AT_SETUP([tg1])
> printf 'Hello from %s/src/
On Tue, May 29, 2018 at 8:10 PM, Eric Blake wrote:
> On 05/29/2018 08:25 PM, John Calcote wrote:
>
>> I'm trying to create a test using autotest that compares the stdout of my
>> program with a string. Unfortunately, the output of the program contains
>> the path of the
Thanks everyone - great responses! Answers all my questions.
On Fri, Jun 1, 2018 at 1:00 PM, Eric Blake wrote:
> On 06/01/2018 01:45 PM, John Calcote wrote:
>
>> I recently ran across some sample code in section 19.4 of the Autoconf
>> manual (modified slightly
I recently ran across some sample code in section 19.4 of the Autoconf
manual (modified slightly to reduce example):
$(TESTSUITE): $(srcdir)/testsuite.at $(srcdir)/package.m4
autom4te --language=autotest -I '$(srcdir)' -o $@.tmp $@.at
mv $@.tmp $@
This question isn't about
On Sun, Jul 1, 2018, 2:54 PM Sascha Manns wrote:
>
> [ 22s] checking that generated files are newer than configure... done
> [ 22s] configure: creating ./config.status [ 22s] config.status: error:
> cannot find input file: ` .in'
>
This error is coming from the AC_CONFIG_FILES line. You seem to
On Mon, Jul 2, 2018 at 3:27 PM Eric Blake wrote:
> On 07/01/2018 10:13 PM, John Calcote wrote:
> > On Sun, Jul 1, 2018, 2:54 PM Sascha Manns
> wrote:
>
> > Start by removing all of the lines in the macro argument that end in .in.
>
> Well, most of them. But po/Makefi
Josh - that's wonderful! Love the video.
On Thu, Aug 20, 2020 at 12:10 PM Joshua Branson via Discussion list for the
autoconf build system wrote:
>
> I made a little goofy video with host Bob Ross for your release
> announcement!
>
> Thanks for the hard work!
>
>
>
On Wed, Jan 6, 2021 at 1:56 PM Eli Schwartz wrote:
> On 1/5/21 9:31 AM, Zack Weinberg wrote:
> > On Mon, Jan 4, 2021 at 5:52 PM Paul Eggert wrote:
> >> On 1/4/21 1:45 PM, Zack Weinberg wrote:
> >>
> >>> it sounds like your concern is not so much with a three-part
> >>> _numbering scheme_, but
Woohoo!! About time! :)
On Tue, Dec 8, 2020 at 12:14 PM Zack Weinberg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> We are pleased to announce stable release 2.70 of GNU Autoconf.
>
> This release includes eight years of development work since the
> previous release, 2.69.
Zack,
Thank you for all the work and time you put into this project. I think I
speak for the community when I say this was a true gift.
John
On Tue, Dec 1, 2020, 9:26 AM wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> It's been four weeks since the release of autoconf 2.69d. I
On Mon, Jan 25, 2021 at 12:26 PM Nick Bowler wrote:
> On 2021-01-25, Zack Weinberg wrote:
> > I'm not at all familiar with Automake's internals, but the reason I
> > suggested taking advantage of GNU make extensions was the potential
> > for _complexity_ reduction of the generated Makefile, not
1 - 100 of 109 matches
Mail list logo
