Re: portability of xargs

On Tue, Feb 15, 2022 at 6:01 PM Bob Friesenhahn wrote: > The people who tell me it is more portable are very interested in > targeting Microsoft Windows. Introduce them to mingw-w64.sf.net + msys2 :) I heard good things about those :P > The "Makefiles" that Cmake generates are self-referential

Re: Future plans for Autotools

On Thu, May 6, 2021 at 4:44 PM Bob Friesenhahn wrote: > > On Thu, 6 May 2021, Karl Berry wrote: > > > > (*) https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html > > So far the response has been nil. > > I don't recall seeing that email. I did see an email thread regarding > Autoconf

Re: Future plans for Autotools

On Mon, May 3, 2021 at 5:34 AM Thomas Jahns wrote: > > - Our code is a mix of Fortran and C, with a bit of C++. Automake still > > deos not support Fortran 90-type module dependencies, so we have to manage > > manual dependencies in one of our Makefile.am's. More modern systems handle > >

Re: [GSoC] Proposal for "Parse Makefile.am using an AST"

On Mar 7, 2018 16:05, "Mathieu Lirzin" wrote: John Calcote writes: > Hi Matthias, > > If you have any suggestions on documents I can read or software I can check >> to >> prepare for this project I'll be glad to check them. I know texinfo is >> written >>

Re: manual: Why use 'maude' as the example program name?

On Wed, Feb 28, 2018 at 11:59 AM, Gavin Smith wrote: > On 25 February 2018 at 19:13, Jonas Thiem wrote: > > Disclaimer: I haven't read this part of the docs myself. But for what > > it's worth, I think Maude looks a bit like a misspelling of Make and

Re: Should Automake still support Java?

On Mon, Oct 30, 2017 at 12:09 PM, Mathieu Lirzin wrote: > Hello, > >Currently Automake supports two ways of compiling Java code. One is > with the 'javac' compiler which is deprecated on the Automake side, and > the other (the recommanded one) which uses GCJ. Relying on GCJ

Re: undeprecate request

On Fri, Aug 19, 2016 at 1:15 AM, Václav Haisman <vhais...@gmail.com> wrote: > On 18.8.2016 21:12, NightStrike wrote: >> Can you undeprecate Java? >> >> https://www.gnu.org/software/automake/manual/html_node/Java.html >> >> I know the support isn't perfect, bu

undeprecate request

Can you undeprecate Java? https://www.gnu.org/software/automake/manual/html_node/Java.html I know the support isn't perfect, but it is useful when you have a large project that incorporates both Java and other languages, and you want to keep yourself in the make world instead of having to have

Re: regex bug on arch

Thanks! On Tue, May 10, 2016 at 1:42 AM, Philipp Thomas <p...@suse.de> wrote: > * NightStrike (nightstr...@gmail.com) [20160510 04:20]: > > >> 1.15 > > This has been fixed in git with commit > 13f00eb4493c217269b76614759e452d8302955e : > > diff --git a/bin/a

Re: regex bug on arch

1.15 On May 9, 2016 4:38 AM, "Philipp Thomas" <p...@suse.de> wrote: > * NightStrike (nightstr...@gmail.com) [20160506 18:50]: > > With the latest automake on archi linux, > > Which is ('automake --version' tells you)? > > > I get this: > > Unesc

regex bug on arch

With the latest automake on archi linux, I get this: Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /usr/bin/automake line 3936.

Re: GNU Automake 1.14 released

On Fri, Jun 21, 2013 at 8:01 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: We are pleased to announce the GNU Automake 1.14 minor release. This release comes with two important changes: 1. It introduces a new feature aimed at making the implementation of non-recursive build

Re: custom silent rule not working in MSYS

On Thu, Mar 21, 2013 at 12:29 PM, Vincent Torri vincent.to...@gmail.com wrote: Hey In MSYS, the following code is not silent (sed_process is a sed command) : pc_verbose = $(pc_verbose_@AM_V@) pc_verbose_ = $(pc_verbose_@AM_DEFAULT_V@) pc_verbose_0 = @echo PC $@; etui.pc:

Re: make distcheck fails when modules not installed

On Sun, Mar 10, 2013 at 10:27 AM, Nate Bargmann n...@n0nb.us wrote: This is a long-standing bug in our project and I've yet to figure out how to address it. The project is primarily a library that once installed has a front end installed in libdir and N back ends (linked by libtool with the

Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS

On Fri, Feb 1, 2013 at 4:35 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: I should at this point decide whether just devote my Automake time to mainline Automake (which amounts at letting Automake-NG die, basically) or to Automake-NG (after tying some loose ends in the mainline

Re: Removal of INCLUDES in favour of AM_CPPFLAGS

On Fri, Feb 1, 2013 at 4:35 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: I should at this point decide whether just devote my Automake time to mainline Automake (which amounts at letting Automake-NG die, basically) or to Automake-NG (after tying some loose ends in the mainline

Re: Create Shared object without .la file - PAM Module -

On Fri, Dec 21, 2012 at 12:28 PM, David Boesner david.boes...@gmail.com wrote: Hi everyone, I'm working on a PAM module. Therefore it is necessary to create a shared object in /lib/security. That words fine. My problem is, that the .la file is also created next to the so file. That's why I

AM_CFLAGS no longer in the manual

I was looking in the manual to see what the default definition of AM_CFLAGS was. It's gone. Instead, all I see is this: AM_CFLAGS This is the variable the Makefile.am author can use to pass in additional C compiler flags. It is more fully documented elsewhere. In some situations, this is not

Re: AM_CFLAGS no longer in the manual

On Sun, Dec 9, 2012 at 10:44 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 09/12/2012 17:32, NightStrike wrote: It's not more fully documented elsewhere, though. AM_CPPFLAGS right about it is, however, fully documented right in this section. This should be fixed, since nowhere does

Re: looking for a good example of non-recursive Make using project

On Tue, Nov 20, 2012 at 5:25 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Tue, 20 Nov 2012, Peter Johansson wrote: Makefile.am [in topdir]. For those fragment files, it would probably be confusing if paths were inserted into variables. Perhaps one could have a switch to turn

Re: How Do Parallel Builds Scale?

On Sat, Nov 17, 2012 at 7:30 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: I suspect that this anaysis has been mentioned on the Automake list before but (if so) it is worth looking at again. It seems that few packages benefit significantly from parallel builds. Many packages use

Re: looking for a good example of non-recursive Make using project

On Sat, Nov 17, 2012 at 12:13 AM, Václav Zeman vhais...@gmail.com wrote: Hi. I am looking for a good example of a project with non-recursive Make that is using Automake, that is not trivial. I would like to convert my project, log4cplus, to non-recursive Make style, if it is possible. Any

Re: Splitting make check into separate build and run targets

On Fri, Nov 16, 2012 at 2:38 AM, Björn Stenberg b...@enea.com wrote: Stefano Lattarini wrote: Couldn't you simply add a 'buil-tests' target that creates all the programs in $(TESTS)? Something as simple as: build-tests: $(TESTS) Then run it on the build system, before running make

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

On Wed, Oct 17, 2012 at 11:27 AM, Gary V. Vaughan g...@gnu.org wrote: Thanks to everyone for your feedback. Much appreciated. It seems that merging libtool into Automake would be an unpopular move all around, with significant downsides for users, so I no longer plan to do that... unless

Re: help to create automake

On Wed, Oct 3, 2012 at 12:56 PM, Ralf Corsepius rc040...@freenet.de wrote: On 10/03/2012 05:29 PM, Rudra Banerjee wrote: Yes, I got some site on non-recursive automake. But I have one more queries: I have 100+ routine in src/. Do I need to enter ALL of them manually as automake do not like

Re: with MSYS (Windows), the hook is not executed after the main rule's work is done

On Fri, Jul 27, 2012 at 9:39 AM, Vincent Torri vincent.to...@gmail.com wrote: hey I want to delete the .la file installed by libtool (note that i don't want to discuss if it's reasonnable or not to delete these files) So, in my Makefile.am, I do: lib_LTLIBRARIES = libevil.la ... ...

AC_CANONICAL_* and automake variables

http://www.gnu.org/savannah-checkouts/gnu/automake/manual/html_node/Optional.html This link says that the canonical macros will make build/host/target_triplet make variables available. What's the difference between using for instance $target and $target_triplet? Will they always be the same?

Re: How to use BUILT_SOURCES ?

On Thu, Jun 21, 2012 at 7:20 AM, Timothy Madden terminato...@gmail.com wrote: Hello I have automake 1.11.1 (on CentOS 6.2 x86_64), and a Makefile.am like this: AM_YFLAGS=-d BUILT_SOURCES=position.hh location.hh code-formatter-parser.hh stack.hh bin_PROGRAMS=code-formatter

Re: compiling different files with different C compilers

On Thu, Jun 7, 2012 at 12:35 PM, Vincent Torri vincent.to...@gmail.com wrote: Hey suppose that my program is composed of 2 files f1.c and f2.c. f1.c is written in C89 and f2.c in C99. I would like that f1.c is compiled with a C89 compiler  and f2.c is compiled with a C99 compiler. How can I

Re: dealing with executable shell scripts

On Thu, Mar 22, 2012 at 4:00 AM, Miles Bader mi...@gnu.org wrote: Russ Allbery r...@stanford.edu writes: [Relying on source-code execute bits always being correctly maintained is one of those things that ... well... doesn't really feel very robust.  I dunno, maybe it's just me...] Doesn't

Re: dealing with executable shell scripts

On Tue, Mar 20, 2012 at 9:06 PM, Miles Bader mi...@gnu.org wrote: 2012年3月21日13:13 NightStrike nightstr...@gmail.com: Here's a better question.  How do you insure that your current file is executable?  Do it the same way. Er cp $ $@ chmod +x $@ ... :] [Relying on source-code execute

Re: dealing with executable shell scripts

On Mon, Mar 19, 2012 at 3:18 PM, Miles Bader mi...@gnu.org wrote: Harlan Stenn st...@ntp.org writes: What's the problem with bin_SCRIPTS? Hmm, I didn't know about it, but ... reading the documentation, bin_SCRIPTS doesn't actually seem to do much of anything -- you still have to add your own

Re: dealing with executable shell scripts

On Tue, Mar 20, 2012 at 1:55 PM, Miles Bader mi...@gnu.org wrote: 2012年3月21日8:33 NightStrike nightstr...@gmail.com: bin_SCRIPTS doesn't actually seem to do much of anything -- you still have to add your own rules to handle all the actual work, need to fiddle with EXTRA_DIST and CLEANFILES, etc

Re: dealing with executable shell scripts

On Tue, Mar 20, 2012 at 3:16 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Tue, 20 Mar 2012, NightStrike wrote: Yes.  There's an earlier email in this thread from somebody illustrating that you don't need to morph from source to script if the file doesn't actually get changed

Re: dealing with executable shell scripts

On Tue, Mar 20, 2012 at 5:11 PM, Miles Bader mi...@gnu.org wrote: 2012年3月21日9:32 NightStrike nightstr...@gmail.com: dist_bin_SCRIPTS = aaa That's going to distribute aaa, though, right, not the actual source e.g. aaa.sh? Yes.  There's an earlier email in this thread from somebody

Re: Automake 1.11.2b test release

On Thu, Jan 26, 2012 at 1:47 AM, Ralf Corsepius ralf.corsep...@rtems.org wrote:   - The support for the obscure multilib feature has been deprecated,     and will be moved out of the automake core in the next major Automake     release (1.12). Bummer - Please reconsider this and understand

Re: allowing users to add source files without rerunning the autotools?

On Wed, Jan 18, 2012 at 8:49 PM, Miles Bader mi...@gnu.org wrote: For cleaning non-automake-handled stuff, you can add a clean-local: rule (and maintainer-clean-local: etc) that does cleaning however you want.  The automake-generated clean rule will depend on it, but you control what it does.  

bug#9855: CFLAGS per source

When using automake, I know how to set *FLAGS globally (ie, AM_*FLAGS), and per binary/lib (ie bin_PROGRAMS=foo ; foo_*FLAGS = ...)  However, those flag variables apply to every source file for a given primary.  What if I have multiple sources that are compiled differently? bin_PROGRAMS = a

Re: CFLAGS per source

Ping On Tue, Oct 18, 2011 at 10:49 AM, NightStrike nightstr...@gmail.com wrote: When using automake, I know how to set *FLAGS globally (ie, AM_*FLAGS), and per binary/lib (ie bin_PROGRAMS=foo ; foo_*FLAGS = ...)  However, those flag variables apply to every source file for a given primary

Re: CFLAGS per source

On Sun, Oct 23, 2011 at 2:12 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On Sunday 23 October 2011, NightStrike  wrote: Ping I'm not going to look into this right now, sorry.  If you want, please open a ticket in the automake bug tracker (by sending a proper mail to bug-autom

CFLAGS per source

When using automake, I know how to set *FLAGS globally (ie, AM_*FLAGS), and per binary/lib (ie bin_PROGRAMS=foo ; foo_*FLAGS = ...) However, those flag variables apply to every source file for a given primary. What if I have multiple sources that are compiled differently? bin_PROGRAMS = a

bug#9088: Java support

On Wed, Jul 20, 2011 at 1:04 AM, tsuna tsuna...@gmail.com wrote: What would be nice would be to have the ability to recompile only the .java that changed.  So when you edit 2/3 files, then we'd build just that, but in one command. make can handle this pretty well. If all the source files are

Re: bug#9088: Java support

On Wed, Jul 20, 2011 at 1:04 AM, tsuna tsuna...@gmail.com wrote: What would be nice would be to have the ability to recompile only the .java that changed.  So when you edit 2/3 files, then we'd build just that, but in one command. make can handle this pretty well. If all the source files are

Re: [GSoC Proposal] automake - Exploit more features of GNU make in Automake

On Tue, Mar 29, 2011 at 2:53 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: On Tuesday 29 March 2011, Dr David wrote: On 03/29/11 12:19 AM, Stefano Lattarini wrote: On Saturday 19 March 2011, Stefano Lattarini wrote: ABSTRACT:    The primary target of this project is to enable

Re: GSoC project idea: non-recursive automake project

On Mon, Mar 21, 2011 at 3:09 PM, Nick Bowler nbow...@elliptictech.com wrote:  * Modify gnulib so that it can be easily integrated into a    non-recursive automake setup.  One could look to libltdl for    inspiration here. How about modifying GCC. That should take some time, I think :) :) :)

Re: Test support for automake

On Sat, Feb 12, 2011 at 4:51 PM, Daily, Jeff A jeff.da...@pnl.gov wrote: From: automake-bounces+jeff.daily=pnl@gnu.org [automake-bounces+jeff.daily=pnl@gnu.org] On Behalf Of Ralf Hemmecke [hemme...@gmail.com] Sent: Friday, February 11, 2011 11:18 AM To: automake@gnu.org Subject:

Re: [CRAZY PROPOSAL] Automake should support only GNU make

On 1/13/11, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: make is a bit flawed for real large projects because it always walks the whole dependency graph, unlike beta build systems who use a notify daemon and a database to only walk subgraphs known to be outdated. How big is real large? GCC

Re: Automake and AR

On Thu, Dec 9, 2010 at 10:11 AM, NightStrike nightstr...@gmail.com wrote: On Sat, Nov 27, 2010 at 10:25 AM, NightStrike nightstr...@gmail.com wrote: On Sun, Oct 31, 2010 at 9:37 AM, NightStrike nightstr...@gmail.com wrote: On Fri, Oct 22, 2010 at 1:07 PM, NightStrike nightstr...@gmail.com wrote

Re: Automake and AR

On Tue, Jan 4, 2011 at 1:10 PM, Peter Rosin p...@lysator.liu.se wrote: Den 2011-01-04 16:23 skrev NightStrike: On Thu, Dec 9, 2010 at 10:11 AM, NightStrike nightstr...@gmail.com wrote: On Sat, Nov 27, 2010 at 10:25 AM, NightStrike nightstr...@gmail.com wrote: On Sun, Oct 31, 2010 at 9:37 AM

Re: Automake and AR

On Sat, Nov 27, 2010 at 10:25 AM, NightStrike nightstr...@gmail.com wrote: On Sun, Oct 31, 2010 at 9:37 AM, NightStrike nightstr...@gmail.com wrote: On Fri, Oct 22, 2010 at 1:07 PM, NightStrike nightstr...@gmail.com wrote: On Wed, Mar 3, 2010 at 3:51 PM, Ralf Wildenhues ralf.wildenh...@gmx.de

Re: Automake and AR

On Sun, Oct 31, 2010 at 9:37 AM, NightStrike nightstr...@gmail.com wrote: On Fri, Oct 22, 2010 at 1:07 PM, NightStrike nightstr...@gmail.com wrote: On Wed, Mar 3, 2010 at 3:51 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * NightStrike wrote on Wed, Mar 03, 2010 at 06:59:53PM CET

Re: Automake and AR

On Fri, Oct 22, 2010 at 1:07 PM, NightStrike nightstr...@gmail.com wrote: On Wed, Mar 3, 2010 at 3:51 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * NightStrike wrote on Wed, Mar 03, 2010 at 06:59:53PM CET: Automake somehow defines AR to 'ar'.  I'm not sure where this comes from, but I

Re: Automake and AR

On Wed, Mar 3, 2010 at 3:51 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * NightStrike wrote on Wed, Mar 03, 2010 at 06:59:53PM CET: Automake somehow defines AR to 'ar'.  I'm not sure where this comes from, but I do know that it's definitely not $host-ar, as I would expect

Re: check_PROGRAMS LDADD

On Wed, Oct 20, 2010 at 1:01 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello Patrick, * Patrick Rutkowski wrote on Wed, Oct 20, 2010 at 03:26:52AM CEST: test_avl_avl_iter_test_LDADD    = -lquark test_avl_avl_test_LDADD         = -lquark test_unicode_unicode_test_LDADD = -lquark

Re: Call for help: Vala support in Automake

On Sun, Aug 8, 2010 at 5:52 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Here's the deal: At least two patch sets have been posted to Automake mailing lists during the last year in order to improve Vala support in What's Vala?

Re: conditionals in Makefile.am

On Wed, Jun 30, 2010 at 9:56 AM, John Calcote john.calc...@gmail.com wrote: On 6/30/2010 3:41 AM, Wesley Smith wrote: From the automake manual: You may only test a single variable in an if statement, possibly negated using ‘!’. The else statement may be omitted. Conditionals may be nested to

Re: cross-compiling but keeping one target native

On Sat, May 15, 2010 at 5:26 AM, Simon Richter simon.rich...@hogyros.de wrote: It's more related to autoconf than to automake. Oops :) Sorry for replying too quickly on the autoconf list :(

Re: Built-in target to delete all generated files

On Thu, Apr 29, 2010 at 7:53 PM, Russ Allbery r...@stanford.edu wrote: Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: My project uses maintainer-mode and I always check these generated files into the source code repository.  The end user might not be able to produce a working set of

Re: Built-in target to delete all generated files

On Thu, Apr 29, 2010 at 11:11 PM, Russ Allbery r...@stanford.edu wrote: NightStrike nightstr...@gmail.com writes: On Thu, Apr 29, 2010 at 7:53 PM, Russ Allbery r...@stanford.edu wrote: I suspect it depends on what sort of activities you expect people using a VCS checkout directly to be doing

Re: Teaching automake about dll defs

On Mon, Apr 19, 2010 at 1:15 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello, * NightStrike wrote on Mon, Apr 19, 2010 at 05:09:04PM CEST: Is this possible?  Is there anyone willing to do it? Addendum:  A big benefit for me (other than many other things) is that it lets automake

Re: GNU autogen code generation

On Tue, Apr 27, 2010 at 4:20 PM, Matěj Týč matej@gmail.com wrote: Hello, I use GNU Autogen to generate files to my project. A little introduction: Autogen uses two files: A definition file, let's say foo.def and a template file, may be foo-template.tpl If I pass the definition file to

Re: Regarding the JAVA primary

On Mon, Apr 19, 2010 at 2:25 PM, John Calcote john.calc...@gmail.com wrote: A problem I foresee is providing the globbing functionality to makefile commands. We'd almost need a new auxiliary script (like install-sh) to generate lists of files from such glob specs. Not sure yet from where the

Re: Teaching automake about dll defs

On Wed, Apr 14, 2010 at 9:49 PM, NightStrike nightstr...@gmail.com wrote: On Sat, Apr 10, 2010 at 9:46 PM, NightStrike nightstr...@gmail.com wrote: On Sat, Apr 10, 2010 at 9:43 PM, NightStrike nightstr...@gmail.com wrote: Would it be out of the question to teach automake how to handle a def

Re: Teaching automake about dll defs

On Sat, Apr 10, 2010 at 9:46 PM, NightStrike nightstr...@gmail.com wrote: On Sat, Apr 10, 2010 at 9:43 PM, NightStrike nightstr...@gmail.com wrote: Would it be out of the question to teach automake how to handle a def file as a source file for a library?  On windows platforms, we typically do

Re: Custom make rules yield ambiguous result

On Sat, Apr 10, 2010 at 2:57 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello, * NightStrike wrote on Sat, Apr 10, 2010 at 12:32:37AM CEST: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-crt/Makefile.am?revision=2163view=markup Down at lines 937 to 941

Teaching automake about dll defs

Would it be out of the question to teach automake how to handle a def file as a source file for a library? On windows platforms, we typically do something like this after building the libx.a file: $triplet-dlltool -k --as=$triplet-as --output-lib=libx.a --def=x.def --as-flags=$(ASFLAGS) I

Re: Teaching automake about dll defs

On Sat, Apr 10, 2010 at 9:43 PM, NightStrike nightstr...@gmail.com wrote: Would it be out of the question to teach automake how to handle a def file as a source file for a library?  On windows platforms, we typically do something like this after building the libx.a file: $triplet-dlltool -k

Re: Sun compiler and /usr/local/include

On Fri, Mar 5, 2010 at 4:13 PM, Charles Brown charles.br...@sensis.com wrote: Dave Hart wrote: On Fri, Mar 5, 2010 at 19:25 UTC, Charles Brown wrote:     Very new to automake, and can't find an answer to this; What would be put in   configure.ac to determine whether the detected

Re: AM_PROG_AS

On Wed, Mar 3, 2010 at 8:53 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * NightStrike wrote on Wed, Mar 03, 2010 at 08:18:14PM CET: Using AM_PROG_AS seems to set AS to 'as' instead of $host-as.  Is this another case of user error, or is this an automake bug? AM_PROG_AS does not set

Re: unconditional version of EXTRA_DIST

On Thu, Mar 4, 2010 at 3:10 AM, Andreas Jellinghaus a...@dungeon.inka.de wrote: Am Donnerstag 04 März 2010 03:31:04 schrieb Ralf Wildenhues: ah. ok, so back to the drawing board for my plan with optional documentation (see the thread a week ago or so). You can use either of - wildcards,  

Automake and AR

Automake somehow defines AR to 'ar'. I'm not sure where this comes from, but I do know that it's definitely not $host-ar, as I would expect. Is this an automake bug, or user error?

AM_PROG_AS

Using AM_PROG_AS seems to set AS to 'as' instead of $host-as. Is this another case of user error, or is this an automake bug?

Re: distcheck and canonical_*

On Wed, Mar 3, 2010 at 1:03 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Steffen Dettmer wrote on Wed, Mar 03, 2010 at 12:21:32AM CET: On Fri, Feb 26, 2010 at 2:55 PM, NightStrike wrote: When doing a make distcheck, why is for instance the --host option not propagated to configure

Re: Automake and AR

On Wed, Mar 3, 2010 at 2:51 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * NightStrike wrote on Wed, Mar 03, 2010 at 06:59:53PM CET: Automake somehow defines AR to 'ar'.  I'm not sure where this comes from, but I do know that it's definitely not $host-ar, as I would expect

Re: Public header files

On Mon, Mar 1, 2010 at 7:33 AM, Jef Driesen jefdrie...@hotmail.com wrote: Hi, How do I get information generated by autotools into my public header files? For instance I want to define version numbers somewhere in my configure.ac file, and have the same numbers appear in a public header file

Re: distcheck and canonical_*

On Sat, Feb 27, 2010 at 11:39 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello, * NightStrike wrote on Fri, Feb 26, 2010 at 02:55:09PM CET: When doing a make distcheck, why is for instance the --host option not propagated to configure without explicitly setting

distcheck and canonical_*

When doing a make distcheck, why is for instance the --host option not propagated to configure without explicitly setting DISTCHECK_CONFIGURE_FLAGS?

Re: Automake conditionals in autoconf

On Wed, Feb 24, 2010 at 2:23 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: The above looks ok to me.  Since I cannot, from your description, exactly reproduce the code that caused the warning for you, I cannot say whether that was a problem. The code as above does not yet take care of

Distributed files: licenses

Right now, we distribute license files in the source archives by adding them to the EXTRA_DIST variable. We do not, however, include the license files in tarballs that we make and distribute of the BINARY archives. I know automake has a lot ofrules and stuff detailing how to build and package

Fortran and flag ordering

When I put fortran sources in a binary that also contains C sources, the compiler optimization flags get messed up. Observe: bin_PROGRAMS = xx xx_SOURCES = a.c a.f95 yields: gcc ... -g -O2 ... gfortran ... -g -O2 ... Cool. Now changing it like this: bin_PROGRAMS = xx xx_SOURCES = a.c a.f95

Compiler options checking

What's the preferred autoconf macro to use to check to see if the compiler supports a certain option? We want to see if the version of gcc we are building supports the -municode option.

AC_PROG_AS / AM_PROG_AS

(autoconf 2.63, automake 1.11) Why is AS found with AM_PROG_AS instead of AC_PROG_AS? Why is this an automake thing and not an autoconf thing?

Re: The New parallel-tests Framework (was: Various testsuites)

On Thu, May 21, 2009 at 1:58 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello once again, allow me to expand upon this topic a bit more.  In this message, I will not try to be fair towards the different test suite frameworks; instead, I'll bluntly praise the new parallel-tests driver.  

Various testsuites

What's the difference between using this: http://www.gnu.org/software/autoconf/manual/autoconf.html#Using-Autotest and this: http://www.gnu.org/software/automake/manual/automake.html#Tests ? Which is better to use? Which will be maintained, and more future-proof? Why is there duplication

Re: My project can't use `silent-rules'

On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: I see that the only way to request the new `silent-rules' feature is by using the new form of AM_INIT_AUTOMAKE to pass the option.  Since my package can not use the new form of AM_INIT_AUTOMAKE, then it can not

Automake 1.10.2 and color-tests

I'm trying to use the new color-tests option as documented here: http://www.gnu.org/software/hello/manual/automake/Tests.html#Tests This online manual is listed as being for automake 1.10.2 here: http://www.gnu.org/software/hello/manual/automake/index.html#Top This manual is for GNU Automake

Re: Automake 1.10.2 and color-tests

On Sat, May 9, 2009 at 4:59 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Hello, * NightStrike wrote on Sat, May 09, 2009 at 10:51:15AM CEST: I'm trying to use the new color-tests option as documented here: http://www.gnu.org/software/hello/manual/automake/Tests.html#Tests http

Re: Does using automake+autoconf require my project to be GPL'ed?

On Mon, Mar 9, 2009 at 2:58 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: We are in the process of moving to GPLv3+ plus exceptions.  The lawyerese process for rewriting the exception specification is not fully done yet, which is why Autoconf 1.10 has been released with GPLv2+ plus Has

Re: GNU Make Extensions

On Fri, Dec 12, 2008 at 10:34 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Fri, 12 Dec 2008, NightStrike wrote: I thought this only occurred when maintainer mode was turned on, and that releases should be made with that turned off. Is that not how it works? Maintainer mode

Re: GNU Make Extensions

On Tue, Dec 16, 2008 at 2:48 AM, NightStrike nightstr...@gmail.com wrote: On Fri, Dec 12, 2008 at 10:34 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Fri, 12 Dec 2008, NightStrike wrote: I thought this only occurred when maintainer mode was turned on, and that releases should

Re: GNU Make Extensions

On Thu, Dec 11, 2008 at 12:04 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Thu, 11 Dec 2008, Duft Markus wrote: There is a philosophical stance that the software we develop is intended for the software users rather than the software developer. There is a problem if build

Re: GNU Make Extensions

On Wed, Dec 10, 2008 at 1:39 AM, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello Tom, * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET: Is it legal to use the += operator in lieu of \ when listing members of a variable in Makefile.am's? Yes. In this case, an Automake extension

Re: GNU Make Extensions

On Wed, Dec 10, 2008 at 10:35 AM, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Wed, 10 Dec 2008, NightStrike wrote: If automake has the ability to flatten the += syntax so that non-portable make advances can be used, why can't the same logic apply to wildcard usage? The biggest argument

Re: GNU Make Extensions

On Wed, Dec 10, 2008 at 10:57 AM, Bob Friesenhahn [EMAIL PROTECTED] wrote: On Wed, 10 Dec 2008, NightStrike wrote: Shouldn't the onus be on me, as the project maintainer, to accept that risk and craft the wildcards properly? I for one would wager heavily that the probability of that being

Re: Multilib sources and variables

On Sun, Nov 30, 2008 at 7:10 AM, Jan Engelhardt [EMAIL PROTECTED] wrote: On Sunday 2008-11-30 02:24, Jan Engelhardt wrote: On Sunday 2008-11-30 01:52, NightStrike wrote: Is the following kosher? It will produce two 32-bit libraries on all architectures where gcc defaults to a 32-bit output

Re: Multilib sources and variables

On Sun, Nov 30, 2008 at 2:32 AM, Ralf Wildenhues wrote: * NightStrike wrote on Sun, Nov 30, 2008 at 01:52:23AM CET: Is the following kosher? Yes, except that you need to use $(shell32src) instead of $shell32src in both places. Noted, thanks! shell32src=libsrc/shell32.c lib32_LIBRARIES

Multilib sources and variables

Is the following kosher? shell32src=libsrc/shell32.c lib32_LIBRARIES += lib32/libshell32.a lib32_libshell32_a_SOURCES = $shell32src lib32_libshell32_a_CPPFLAGS = -m32 lib64_LIBRARIES += lib64/libshell32.a lib64_libshell32_a_SOURCES = $shell32src Basically, all the sources are the same, so I

Re: per-directory options

On Thu, Sep 18, 2008 at 5:31 PM, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hello, * NightStrike wrote on Thu, Sep 18, 2008 at 08:01:19PM CEST: Does automake yet support doing something like this?: mylibdir_LIBRARIES=liba.a libb.b mylibdir_CPPFLAGS=-m32 mylibdir_liba_a_SOURCES=a.c

per-directory options

Does automake yet support doing something like this?: mylibdir_LIBRARIES=liba.a libb.b mylibdir_CPPFLAGS=-m32 mylibdir_liba_a_SOURCES=a.c mylibdir_libb_a_SOURCES=b.c that is, allowing me to avoid the two lines: mylibdir_liba_a_CPPFLAGS=-m32 mylibdir_libb_a_CPPFLAGS=-m32 I know I ask about it

flag question

-Wall and -pedantic... AM_CFLAGS or AM_CPPFLAGS?

  1   2   >