Re: Automake (alpha) release request

On 12/16/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Sebastian, > > * Sebastian Pipping wrote on Fri, Dec 14, 2007 at 08:08:41PM CET: > > > > I found out Automake does support LZMA for some time now > > but no release (not even alpha) has been made after. > > We're still waiting for >

Re: Automake (alpha) release request

On 12/16/07, Bob Proulx <[EMAIL PROTECTED]> wrote: > NightStrike wrote: > > When you do make a release, where will be the list of new features located? > > The NEWS file is the standard location to list new features. > > The NEWS file as currently in version control

Re: Automake (alpha) release request

On 12/17/07, Brian Dessent <[EMAIL PROTECTED]> wrote: > Sebastian Pipping wrote: > > > Bob Friesenhahn wrote: > > > The license update can simply be temporarily reverted back to v2 (with > > > FSF approval). > > > > I'd like to see that as well but I doubt it will happen. > > It's not politically f

Re: DLLTOOL without LIBTOOL

On 11/2/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello NightStrike, whoever you are, > > * NightStrike wrote on Fri, Nov 02, 2007 at 05:29:01PM CET: > > Currently, the macro AC_PROG_LIBTOOL will search for dlltool and > > define $(DLLTOOL) appropriately. If I o

Small documentation issue

I noticed that on Page 16 (printed page 16, pdf page 18) of the pdf version of the manual available here: http://www.gnu.org/software/automake/manual/automake.pdf that there is the sentence: AC_INIT takes in parameters the name of the package, its version number, and a contact address for bugrep

Re: Small documentation issue

On 1/13/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello, > > * NightStrike wrote on Sun, Jan 13, 2008 at 10:08:58AM CET: > > > > AC_INIT takes in parameters the name of the package, its version > > number, and a contact address for bugreports about the packa

Re: Small documentation issue

On 1/14/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Thanks for your findings and suggestions, I fixed them as below and put > you in THANKS. Please consider just sending patches to the source, to > the automake-patches list. Here's another: index 8b51080..9d311be 100644 --- a/doc/automake.t

Re: Small documentation issue

On 1/17/08, NightStrike <[EMAIL PROTECTED]> wrote: > On 1/14/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > Thanks for your findings and suggestions, I fixed them as below and put > > you in THANKS. Please consider just sending patches to the source, to &g

Re: GNU Automake 1.10.1 released

On 1/21/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > - Fix order of standard includes to again be `-I. -I$(srcdir)', >followed by directories containing config headers. What was it before the fix?

make install / parallel

Does automake allowing doing something like: make -j5 install ? I ask because executing /usr/bin/install for several thousand files is incredibly slow (it takes longer to install than to build each of these files). Running several in parallel may make it go faster, as there's a lot of IO and ve

Re: make install / parallel

On 1/28/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello, > > * NightStrike wrote on Fri, Jan 25, 2008 at 01:24:57PM CET: > > Does automake allowing doing something like: > > > > make -j5 install ? > > It should, yes, in the sense that it should no

make help?

Is there any possibility of an automake generated "help" target that would list the possible targets (or a subset of them) for make? This could potentially be propagated upstream to the standard gnu targets, too.

Re: make help?

On 2/3/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * NightStrike wrote on Sun, Feb 03, 2008 at 03:53:36PM CET: > > Is there any possibility of an automake generated "help" target that > > would list the possible targets (or a subset of them) for make? This >

Re: make help?

On 2/3/08, NightStrike <[EMAIL PROTECTED]> wrote: > On 2/3/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > * NightStrike wrote on Sun, Feb 03, 2008 at 03:53:36PM CET: > > > Is there any possibility of an automake generated "help" target that > > >

Re: make install / parallel

On 1/28/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * NightStrike wrote on Mon, Jan 28, 2008 at 11:14:32PM CET: > > On 1/28/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > > <http://lists.gnu.org/archive/html/automake-patches/2008-01/msg00070.html> >

AM_INIT_AUTOMAKE uses a deprecated macro

When I use AM_INIT_AUTOMAKE, it makes use of _AM_SET_OPTIONS, which uses AC_FOREACH, which is deprecated in autoconf and referenced in the autoconf manual as deprecated. I thought I was using all of the "latest and greatest" tools. Has this been updated? If so, how/where do I get the update?

Shared without libtool

Does automake support building shared libraries without using libtool?

Re: Shared without libtool

On 3/7/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > On Sat, March 8, 2008 01:11, NightStrike wrote: > > Does automake support building shared libraries without using libtool? > > The question is: why? Hypothetical discussion on the tcl project. > There is no special

Re: Shared without libtool

On 3/7/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > On Sat, March 8, 2008 01:23, NightStrike wrote: > > On 3/7/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > >> On Sat, March 8, 2008 01:11, NightStrike wrote: > >> > Does automake support build

Re: Shared without libtool

On 3/7/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > On Sat, March 8, 2008 01:33, NightStrike wrote: > > On 3/7/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > >> On Sat, March 8, 2008 01:23, NightStrike wrote: > > >> >> > Does autom

Questions on 'make dist'

Project page: http://sourceforge.net/projects/mingw-w64 Our project is laid out like this: /trunk/ /trunk/mingw-w64-crt/ /trunk/mingw-w64-doc/ /trunk/mingw-w64-headers/ In the *-crt directory is where the build system resides, including any headers required to *build* the crt. In the *headers d

Re: Questions on 'make dist'

On Tue, Mar 11, 2008 at 5:41 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * NightStrike wrote on Mon, Mar 10, 2008 at 03:42:52PM CET: > > > Our project is laid out like this: > > > > /trunk/ > > /trunk/mingw-w64-crt/ > > /trunk/mingw-w64-doc/ >

Automake and dejagnu's site.exp file

>From the manual: Automake will generate rules to create a local site.exp file, defining various variables detected by configure. This file is automatically read by DejaGnu. It is OK for the user of a package to edit this file in order to tune the test suite. However this is not the place where th

Re: Questions on 'make dist'

On 3/11/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > On Tue, 11 Mar 2008, NightStrike wrote: > > > > I think I understand what you mean. Create a recursive build tree > > that allows starting from any point. I would then perhaps put this > > also in the trun

Re: Questions on 'make dist'

On 3/11/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > On Tue, 11 Mar 2008, NightStrike wrote: > > > > I think I understand what you mean. Create a recursive build tree > > that allows starting from any point. I would then perhaps put this > > also in the trun

Re: Questions on 'make dist'

On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote: > BTW: Why do you insist on the layout described above? I would have > one top-level directory and make "doc" and "headers" (or perhaps > "hdr") subdirs. The mingw-w64-headers directory contains headers that are required to use the resulting gcc

Re: Questions on 'make dist'

On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote: > Hello, > > On Wed, Mar 19, 2008 at 03:13:06PM -0400, NightStrike wrote: > > On 3/19/08, Stepan Kasal <[EMAIL PROTECTED]> wrote: > > > BTW: Why do you insist on the layout described above? I would have &g

Re: build configuration help

On 4/3/08, Bob Rossi <[EMAIL PROTECTED]> wrote: > On Thu, Apr 03, 2008 at 08:36:44AM -0600, John Calcote wrote: > > Bob, > >> On linux, there is no such guarentee. So, I have come up with 2 > >> solutions, and wonder if someone else has a better idea, or prefers one > >> over the others. > >> > >>

Re: Report to stdout like Linux kernel compilation does

On Fri, Apr 11, 2008 at 5:28 PM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > I can't understand why people do edit-compile-test cycles without having > compiler output be post-processed by their editor. It works with all > decent unix editors, and it's even more comfortable than not having to

Re: CPPFLAGS for LIBOBJS

On 4/23/08, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > * Russ Allbery wrote on Wed, Apr 23, 2008 at 10:51:11PM CEST: > > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > > > Yes, they don't get per-target preprocessor or compile flags. That > > > doesn't work, because then they would have to be

flag question

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

Re: flag question

On 4/25/08, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > NightStrike wrote: > > -Wall and -pedantic... AM_CFLAGS or AM_CPPFLAGS? > > Neither. Neither are portable, so the do not belong in the Makefile.am, > check for gcc in configure and append them to CFLAGS if t

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

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

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 do

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 o

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! >> she

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 Au

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 >&

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 heavi

Re: GNU Make Extensions

On Thu, Dec 11, 2008 at 12:04 PM, Bob Friesenhahn 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 behavior is different f

Re: GNU Make Extensions

On Fri, Dec 12, 2008 at 10:34 AM, Bob Friesenhahn 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 >> w

Re: GNU Make Extensions

On Tue, Dec 16, 2008 at 2:48 AM, NightStrike wrote: > On Fri, Dec 12, 2008 at 10:34 AM, Bob Friesenhahn > wrote: >> On Fri, 12 Dec 2008, NightStrike wrote: >>> >>> I thought this only occurred when "maintainer mode" was turned on, and >>> that

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

On Mon, Mar 9, 2009 at 2:58 PM, Ralf Wildenhues 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 progress been made, or

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 (v

Re: Automake 1.10.2 and color-tests

On Sat, May 9, 2009 at 4:59 AM, Ralf Wildenhues 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/aut

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

On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn 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 request > `silent-rules'.

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 betwe

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

On Thu, May 21, 2009 at 1:58 PM, Ralf Wildenhues 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.  :-) > >> Automake

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?

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.

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 x

Re: Non-recursive automake

On Sun, Oct 18, 2009 at 1:39 AM, Ralf Wildenhues wrote: > Hello, > > * Jan Engelhardt wrote on Sat, Oct 17, 2009 at 07:04:39PM CEST: >> when one decides to drive make in a non-recursive fashion, one has to >> write an Automake file like this: >> >> lib_LTLIBRARIES = foo/bar.la >> foo_bar_la_SOURCE

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 sou

Automake conditionals in autoconf

I'm sending this to both lists because I don't know which one is right. I'm trying to conditionally configure and build subdirectories using Automake conditionals. I'm flipping back and forth between both manuals, so I'm guessing both apply. I have a top level configure/makefile that I'm buildin

Re: Automake conditionals in autoconf

On Wed, Feb 24, 2010 at 2:23 PM, Ralf Wildenhues 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 adjusting SUBDIRS (an

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: distcheck and canonical_*

On Sat, Feb 27, 2010 at 11:39 PM, Ralf Wildenhues 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 >> DISTCHE

Re: Public header files

On Mon, Mar 1, 2010 at 7:33 AM, Jef Driesen 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 without > having t

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 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 >> > prop

Re: Automake and AR

On Wed, Mar 3, 2010 at 2:51 PM, Ralf Wildenhues 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 >&

Re: AM_PROG_AS

On Wed, Mar 3, 2010 at 8:53 PM, Ralf Wildenhues 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

Re: unconditional version of EXTRA_DIST

On Thu, Mar 4, 2010 at 3:10 AM, Andreas Jellinghaus 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, >>    EXT

Re: Sun compiler and /usr/local/include

On Fri, Mar 5, 2010 at 4:13 PM, Charles Brown 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 preprocessor/compile

Custom make rules yield ambiguous result

This is regarding the following file: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-crt/Makefile.am?revision=2163&view=markup Down at lines 937 to 941, there are two sets of rules, one for 3 specific files and one for the rest of the libs we generate: lib64/libcrtdll.a lib

Re: Custom make rules yield ambiguous result

On Sat, Apr 10, 2010 at 2:57 AM, Ralf Wildenhues 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=2163&view=markup >> >> Down at lines

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 notice

Re: Teaching automake about dll defs

On Sat, Apr 10, 2010 at 9:43 PM, NightStrike 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: Teaching automake about dll defs

On Sat, Apr 10, 2010 at 9:46 PM, NightStrike wrote: > On Sat, Apr 10, 2010 at 9:43 PM, NightStrike 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 lik

Re: Teaching automake about dll defs

On Wed, Apr 14, 2010 at 9:49 PM, NightStrike wrote: > On Sat, Apr 10, 2010 at 9:46 PM, NightStrike wrote: >> On Sat, Apr 10, 2010 at 9:43 PM, NightStrike wrote: >>> Would it be out of the question to teach automake how to handle a def >>> file as a source file

Re: Regarding the JAVA primary

On Mon, Apr 19, 2010 at 2:25 PM, John Calcote 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 > primary functionalit

Re: Teaching automake about dll defs

On Mon, Apr 19, 2010 at 1:15 PM, Ralf Wildenhues 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 m

Re: GNU autogen code generation

On Tue, Apr 27, 2010 at 4:20 PM, Matěj Týč 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 autogen, it sh

Re: Built-in target to delete all generated files

On Thu, Apr 29, 2010 at 7:53 PM, Russ Allbery wrote: > Bob Friesenhahn 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 files based on whatever random autotools

Re: Built-in target to delete all generated files

On Thu, Apr 29, 2010 at 11:11 PM, Russ Allbery wrote: > NightStrike writes: >> On Thu, Apr 29, 2010 at 7:53 PM, Russ Allbery wrote: > >>> I suspect it depends on what sort of activities you expect people using >>> a VCS checkout directly to be doing, and also

Re: cross-compiling but keeping one target native

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

Re: conditionals in Makefile.am

On Wed, Jun 30, 2010 at 9:56 AM, John Calcote 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 any depth

Re: Call for help: Vala support in Automake

On Sun, Aug 8, 2010 at 5:52 AM, Ralf Wildenhues 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: check_PROGRAMS & LDADD

On Wed, Oct 20, 2010 at 1:01 AM, Ralf Wildenhues 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: Automake and AR

On Wed, Mar 3, 2010 at 3:51 PM, Ralf Wildenhues 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 >&

Re: Automake and AR

On Fri, Oct 22, 2010 at 1:07 PM, NightStrike wrote: > On Wed, Mar 3, 2010 at 3:51 PM, Ralf Wildenhues > 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 >>>

Re: Automake and AR

On Sun, Oct 31, 2010 at 9:37 AM, NightStrike wrote: > On Fri, Oct 22, 2010 at 1:07 PM, NightStrike wrote: >> On Wed, Mar 3, 2010 at 3:51 PM, Ralf Wildenhues >> wrote: >>> * NightStrike wrote on Wed, Mar 03, 2010 at 06:59:53PM CET: >>>> Automake somehow def

Re: Automake and AR

On Sat, Nov 27, 2010 at 10:25 AM, NightStrike wrote: > On Sun, Oct 31, 2010 at 9:37 AM, NightStrike wrote: >> On Fri, Oct 22, 2010 at 1:07 PM, NightStrike wrote: >>> On Wed, Mar 3, 2010 at 3:51 PM, Ralf Wildenhues >>> wrote: >>>> * NightStrike wrote

Re: Automake and AR

On Thu, Dec 9, 2010 at 10:11 AM, NightStrike wrote: > On Sat, Nov 27, 2010 at 10:25 AM, NightStrike wrote: >> On Sun, Oct 31, 2010 at 9:37 AM, NightStrike wrote: >>> On Fri, Oct 22, 2010 at 1:07 PM, NightStrike wrote: >>>> On Wed, Mar 3, 2010 at 3:51 PM

Re: Automake and AR

On Tue, Jan 4, 2011 at 1:10 PM, Peter Rosin wrote: > Den 2011-01-04 16:23 skrev NightStrike: >> On Thu, Dec 9, 2010 at 10:11 AM, NightStrike wrote: >>> On Sat, Nov 27, 2010 at 10:25 AM, NightStrike wrote: >>>> On Sun, Oct 31, 2010 at 9:37 AM, NightStrike wrote: &

Re: Automake and AR

On Tue, Jan 4, 2011 at 2:50 PM, Ralf Wildenhues wrote: > * NightStrike wrote on Tue, Jan 04, 2011 at 07:18:29PM CET: >> On Tue, Jan 4, 2011 at 1:10 PM, Peter Rosin wrote: >> > Den 2011-01-04 16:23 skrev NightStrike: >> >>>>>> On Wed, Mar 3, 2010 at

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

On 1/13/11, Ralf Wildenhues 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 uses make, for instan

Re: Test support for automake

On Sat, Feb 12, 2011 at 4:51 PM, Daily, Jeff A 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: Test supp

Re: GSoC project idea: non-recursive automake project

On Sat, Mar 19, 2011 at 3:45 PM, Harlan Stenn wrote: > Pippijn wrote: > >> On Fri, Mar 18, 2011 at 05:26:58PM -0700, Harlan Stenn wrote: >> > If there was a student interested in showing how "easy" it was to use >> > automake to do non-recursive Makefiles for a project, I'd be willing to >> > co-m

Re: GSoC project idea: non-recursive automake project

On Mon, Mar 21, 2011 at 3:09 PM, Nick Bowler 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 :) :) :)

<    1   2