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.
http://www.freesoftwaremagazine.com/books/autotools_a_g
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 mak
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= /usr/loc
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 hac
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 ;
return 0;
}
This works f
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
th
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
___
A
On 4/20/2009 6:15 PM, Russ Allbery wrote:
John Calcote 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, and not $INSTALL -m
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 t
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 appropria
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 testing
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 generate
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 i
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 a
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++
prog
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
direct
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 the
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 C
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
director
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 -s
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
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 ./configu
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, m
Hi Andrew,
On 10/23/2009 5:34 PM, Andrew W. Nosenko wrote:
On Fri, Oct 23, 2009 at 00:50, Alfred M. Szmidt 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 hard to me and
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 l
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 I
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 (i.e
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 tot
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; and
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 ca
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
On 6/30/2010 3:48 AM, Andrew W. Nosenko wrote:
>
> Excuse me, but why just don't
>
> #include
>
> 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 t
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 abo
On 7/27/2010 9:44 AM, Alfred M. Szmidt wrote:
> Is this book published under a free documentation license?
>
Hi Alfred,
To be totally honest, I'm not really sure. That may sound funny, but
I've been afraid to push this issue with No Starch Press because I had
to search long and hard for a publis
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,
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
pthread.
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.
&g
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.t
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: WA
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 beca
> 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 ind
>
> 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
> > 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
Use --sysconfdir=/etc when you use --prefix=/usr.
Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone
Original message
From: Roman Neuhauser
Date:03/19/2015 3:49 PM (GMT-07:00)
To: autoconf@gnu.org
Cc:
Subject: sysconfdir
sysconfdir is defined as '${prefix}/e
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 autoconf
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 program. As part of its output, it writes its own program
name (from argv[0]) to stdout, so I have to use ${abs_top_builddir} as part
of
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 fr
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 o
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 autotes
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
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
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 p
our various debug flags to
enable/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 Calco
tion level that I want.
Of course, my 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:
>
On Tue, Feb 07, 2006 at 01:37: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_C
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 co
tion level that I want.
Of course, my 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:
>
--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 mor
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 progra
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&
On Tue, Mar 18, 2008 at 9:05 AM, Dirk <[EMAIL PROTECTED]> wrote:
> I know pretty well what I'm talking about. I was using autoconf for some
> months to configure my projects but then switched to my own solution
> because autoconf was just bloated overkill... overkill that forced me to
> spend t
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):
http://www.freesoftwaremagazin
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-sec
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. I
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/in
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
-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 som
-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
-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,
-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.
Whe
-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 t
-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 file
-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
-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 ab
-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,
- --e
-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 quest
-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 test
-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
-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.
>
&g
-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,
-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/Mak
-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 Wilde
-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
-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 reb
-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
>> or
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!
>
>
> https://video.hardlimit.com/vi
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
1 - 100 of 106 matches
Mail list logo
