Re: parallel build issues

On Jun 21, 2021, at 11:49 AM, Werner LEMBERG wrote: > > bin_PROGRAMS += ttfautohintGUI Is Automake smart enough to realize what you’ve done there? It seems to me this does something down at the GNU make level that should be done up at the Automake level, preventing Automake from building its

Re: Constantly changing libtool

On Apr 15, 2021, at 11:23 AM, Paul Smith wrote: > > On Thu, 2021-04-15 at 08:33 -0500, Laurence Marks wrote: >> there should be a way to autoupdate autoXYZ files for each system autoreconf? https://linux.die.net/man/1/autoreconf >> without user intervention. Post-checkout hooks?

Re: config.sub/config.guess using nonportable $(...) substitutions

On Mar 9, 2021, at 1:26 PM, Paul Eggert wrote: > >> 1) There is no actual benefit to using $(...) over `...`. > > I disagree with that statement on technical grounds (not merely cosmetic > grounds), as I've run into real problems in using `...` along with " and \, Me too, plus nesting. The

Re: Make -j to Compiler Question

On Sep 21, 2019, at 9:55 PM, Nicholas Krause wrote: > > what is the easiest way to get this info into > the gcc frontend. I’m not seeing that this is an Automake topic. The output of Automake is a GNU make file, which doesn’t control how you call “make”. Automake is on the other side of

Re: choosing compilers in config.ca

On Apr 10, 2019, at 1:59 PM, Matt Pratola wrote: > > I am trying to write a config.ac script configure.ac, surely? And speaking of, I’m pretty sure you’ve send this to the wrong list. I don’t see anything in this question that involves Automake; this is all Autoconf stuff. > that will

Re: automake: tap-driver.sh: cleanup and revival.

On Oct 27, 2017, at 7:19 AM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > > On Fri, 27 Oct 2017, Warren Young wrote: >> >> The operating system has a database mapping what my terminal can do to a >> common API. Let the library handle it. > > I

Re: automake: tap-driver.sh: cleanup and revival.

On Oct 25, 2017, at 6:03 PM, Russ Allbery <ea...@eyrie.org> wrote: > > Warren Young <war...@etr-usa.com> writes: > >> As for the portability of ANSI terminal escape codes, it’s still best to >> delegate such things to curses or libraries like it, despite th

Re: automake: tap-driver.sh: cleanup and revival.

On Oct 25, 2017, at 2:51 PM, Mathieu Lirzin <m...@gnu.org> wrote: > > Warren Young <war...@etr-usa.com> writes: > >> As for the portability of ANSI terminal escape codes, it’s still best >> to delegate such things to curses or libraries like it, despite th

Re: automake: tap-driver.sh: cleanup and revival.

On Oct 25, 2017, at 8:56 AM, Bob Friesenhahn wrote: > >> It's also crazy that "--color-tests=y" or "--color-tests=1" won't work > > While I like color in photos and nature, automatic colorization of output > often causes problems for me since it often renders the

Re: Warning - non-POSIX variable name

On Aug 9, 2017, at 11:39 AM, Eric Blake wrote: > > Why not just: > > ./configure CC="$PWD/../../llvm-arm-toolchain-ship/3.8/bin/clang" > > which turns your relative name into an absolute one? > > Do you HAVE to have the canonical name? It just makes the log messages

Re: Warning - non-POSIX variable name

On Aug 9, 2017, at 9:00 AM, Bob Friesenhahn wrote: > > Passing a relative path to CC seems error prone since it only applies to the > current working directory and will fail as soon as any Makefile recurses. Maybe you have a better answer to this related

Re: Warning - non-POSIX variable name

On Aug 7, 2017, at 11:39 PM, Dharmil Shah wrote: > > I followed your suggestions and hence I am able to compile my package using > the llvm compiler. I hope you chose option 3. On re-reading that email, I think option 2 is wrong, or at least, it isn’t what I meant to

Re: Warning - non-POSIX variable name

On Aug 7, 2017, at 5:17 AM, Dharmil Shah wrote: > > I did something like this: > > CC=${CC - /../../llvm-arm-toolchain-ship/3.8/bin/clang} I don’t know that syntax, and due to its form, I’ve failed to Google up a reference to it, so I don’t know what exactly it is you’re

Re: GNU Automake 1.15.1 released

On Jun 19, 2017, at 2:50 PM, Mathieu Lirzin wrote: > > - Automake-provided scripts and makefile recipes might (finally!) >start assuming a POSIX shell in Automake 2.0. There still is no >certainty about this though: we'd first like to wait and see >whether future

Re: More control over 'make dist'

On Sep 14, 2016, at 7:49 AM, Peter Rosin wrote: > > On 2016-09-14 11:33, Michal Privoznik wrote: >> >> ln -s $xml.in $xml.out >> >> However, I was looking into archive produced by 'make dist' the other >> day and found out that the symlinks are not preserved. > > I

Re: [gnu-prog-discuss] Automake dist reproducibility

On Dec 22, 2015, at 2:51 PM, Bob Friesenhahn wrote: > > Attempting to get archiving tools to produce the same results at different > times on different machines is close to impossible Fortunately, others have already done much of the hard work:

Re: [gnu-prog-discuss] Automake dist reproducibility

On Dec 22, 2015, at 12:16 PM, Pádraig Brady wrote: > > On 22/12/15 17:00, Mike Gerwitz wrote: >> There is ongoing discussion about reproducible builds within GNU. > > I’m wondering about how useful deterministic tarballs are? This page gives the “whys” of reproducible

Re: how to use python macros together

On Apr 3, 2015, at 11:55 AM, Andy Falanga (afalanga) afala...@micron.com wrote: It just so happens that, on CentOS 6, the install of python is broken because one cannot do pkg-config --cflags python. Who said you should be able to? I just downloaded the source tarballs for Python 2.6.6

Re: Autotools and CMake

On Dec 26, 2014, at 7:56 AM, Kip Warner k...@thevertigo.com wrote: On Wed, 2014-12-24 at 15:49 -0700, Warren Young wrote: I’d put the “mkdir build ; cd build ; cmake ..” type of stuff in your bootstrap script: I think the logical place to configure another subproject is within

Re: Autotools and CMake

On Dec 23, 2014, at 8:37 PM, Kip Warner k...@thevertigo.com wrote: Hey Stefano, Stefano Lattarini is no longer the Automake maintainer: http://goo.gl/eE1v9R What is the most elegant way of solving this problem that you would suggest? I’d put the “mkdir build ; cd build ; cmake ..” type

Re: Generated Makefile fails to build

On 9/19/2014 17:16, Bob Friesenhahn wrote: On Sat, 20 Sep 2014, Robert Parker wrote: AM_LDFLAGS = -lmhash A library is not a linker flag so it does not belong in LDFLAGS. Look into using a 'LIBADD' type option instead. This problem seems to be a 'feature' of gcc because the same error

Re: automake configure hangs on cygwin

On 6/29/2014 05:18, Chamila Wijayarathna wrote: I downloaded automake 1.14.1, extracted it and ran ./configure using cygwin. It ran a while and hang at checking for yacc. It gets past yacc here, under both Cygwin 32 and Cygwin 64. What does which yacc say? Do you, in fact, have the Cygwin

Re: PCH support

On 12/23/2011 9:46 AM, Stefano Lattarini wrote: I know basically nothing about PCH, The only important thing to know is that it's a way to make the compiler dump its parse tree to disk during compilation so that it can simply reload that state from disk instead of rebuilding it from scratch

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

On 11/22/2011 8:03 PM, Dave Hart wrote: If Autotools are primarily intended to support those using GNU/Linux systems and portability is not a goal, your argument that GNU has won and BSD compatibility of free software is no longer worthwhile makes sense. Where did I say automake 2 =

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

On 11/22/2011 8:06 PM, Harlan Stenn wrote: Warren wrote: On 11/22/2011 6:02 PM, Harlan Stenn wrote: The BSDs have their good reasons to want to avoid GPL'd code, especially GPL3. Besides, why should BSD purity get to hold back the Autotools? So GNU/Linux purity is fine but BSD purity is

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

On 11/23/2011 8:08 AM, Bob Friesenhahn wrote: Beyond that, it mostly comes down to this simple question: What do I type in order to invoke GNU make on this system? No, that's easily wrapped. Aautoconf can write out both a GNUmakefile and a Makefile. When both are present, GNU make will

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

On 11/22/2011 8:50 AM, Bob Friesenhahn wrote: It would be useful to enumerate the user-visible benefits if Automake can depend on using GNU make. - For me, the biggest potential benefit isn't to Automake, but to Autoconf: if it were reimplemented in terms of GNU make, you'd then get

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

On 11/22/2011 10:33 AM, Ralf Corsepius wrote: So far, automake has not been using gmake, so why should it now start doing so? Because gmake is all but ubiquitous, and has been so for a decade. The only exception I can think of is the BSDs, which still stubbornly stick to BSD make,

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

On 11/22/2011 11:18 AM, Ralf Corsepius wrote: is gmake stable enough or is gmake just another moving target just like many other GNU-programs? If you go back just three versions, you've gone back in time ~9 years. That is about the length of time that GNU make has been the default

Re: Could automake-generated Makefiles required GNU make?

On 11/22/2011 9:18 AM, Nick Bowler wrote: users who have no idea that there's a difference between GNU make and the version of make that is already on their system. That's not the user's job today, and there's no reason it would have to be in this new world, either. Autoconf's raison

Re: [gnu-prog-discuss] Could automake-generated Makefiles required GNU make?

On 11/22/2011 7:46 PM, Bob Friesenhahn wrote: P.S. I choose to be a 1 percenter. 1% I'm fine with. It's 0.001% I'm talking about. Do we let OpenVMS drive Autotools' direction, too? OS/2? BeOS? Ooops, nope. GNU make probably shipped on those platforms, too. :)

Re: default -g ??!?

On 11/20/2010 1:05 PM, MK wrote: I do not think the exception (a need for debugging) should make the rule (general use, production grade software). I'd bet 99%+ of the time those compiled in debugging symbols never even get used a single time. The black box on an airplane doesn't get much

Re: incremental make install

Bob Rossi wrote: I was wondering if there is an incremental make install command? (my make install doesn't appear to be incremental, should it be?) No, a Makefile's install target normally just contains a series of commands for installing everything, without checking if it exists first.

Re: incremental make install

Bob Friesenhahn wrote: Perhaps the solution is to use an 'install' program which only copies files if they have changed. Rsync is an example of a program which can do this. rsync doesn't use timestamps. It looks at the entire file contents for both source and target, and performs some

Re: Avoiding multiple identical program-source.o files

chadhogg wrote: Is there a way I can get automake to recognize that it does not need more than one copy of a .o file for a given set of compiler options? It might do what you want if you build these common sources into two convenience libraries -- look that term up in the docs -- and change

Re: Advice on the project structure for a library

Jef Driesen wrote: I noticed it is common practice to install the public headers to $includedir/libfoo I don't think I've ever seen a 'lib' prefix on a header file directory. $includedir/foo is far more common. It's also common for 'foo' to be a diminutive, lowercased version of the

Re: Advice on the project structure for a library

Jef Driesen wrote: I don't really want to mandate a specific style to the users of my library. [snip] Suppose that in one of my public headers, I include one of the other header files, with libfoo/headerx.h style. If your headers use the libfoo/header.h style, your users must, too.

Re: Advice on the project structure for a library

Jef Driesen wrote: If your headers use the libfoo/header.h style, your users must, too. That's not consistent with your wish above. Why is that necessary? Isn't the toplevel directory (where the libfoo/header.h is located) also included, even if the user is using a header.h include style? Or

Re: How to install doxygen-generated HTML documentation?

Peter Simons wrote: dist_pkgdata_DATA = html Try: dist_pkgdata_DATA = html/*

Re: Makefile.am for both windows and linux

Nitin Goyal wrote: I can not use libtools. Is there a way, I can achieve this? Use Bakefile, or cmake, or jam, or something else that really understands Windowsisms. automake can be arm-twisted into supporting native Windows builds, but it isn't happy doing it. I use Bakefile myself; it

Re: Files to keep in a control versioning system

Paulo J. Matos wrote: Which files of a autotools project should be kept in a control versioning system? IMHO, nothing generated goes in the repository. Ever. If that means some developers are using different tools to generate these files and so get different results, that's a good thing:

Re: What to check into repository?

Hongliang Wang wrote: [EMAIL PROTECTED] autoreconf Makefile.am: required file `./NEWS' not found You can create empty versions of these files to appease the tool. (Per the thread topic, they would go in the repository.) Or, maybe you have a use for some of these files, so they could have

Re: Overriding bindir

Jeff Safier wrote: Is there a way to override bindir as not to install into /usr/local/bin? $ ./configure --help Find information on --prefix and such. Enjoy.

Re: autotools not suited to proprietary development?

Andre Stechert wrote: I think you're confusing the idea of a build system for portable software (something the autotools suite can help with) and an installer (or package if you're installing onto a system that has a package manager). Yes. It's not that autotools do the wrong thing, it's

Re: compiling in the build time

David Byron wrote: What I'm having trouble with is getting the builddate.c recipe to happen at the right time. Could you make it depend on *.o except for builddate.o? If any of those change, rebuild builddate.c, which will cause builddate.o to be rebuilt.

Re: 'make clean' is removing too many files

Harald Dunkel wrote: If I add something like lib_LIBRARIES = /some/static/old/lib2install.a ...then you're probably doing something wrong. That should probably go in LDADD.

Re: 'make ctags' and vim

Konstantin Osipov wrote: How do people work around the lack of 'include' directive of ctags? I put this in the Makefile.am in the project's src subdir: tags: find . -name TAGS -o -name tags -exec rm {} \; ctags `pwd`/*/*.cpp `pwd`/*/*.h find . -type d -mindepth 1 -exec ln tags {} \;

Re: Compiling large number of files

v p wrote: Loading 'gcc' into memory for each file is a time consuming process Have you measured this, or are you speculating? If I could make generated makefile do this, my build process will be much faster. This is a limitation of make, not of the autotools.

Re: Compiling large number of files

v p wrote: I have a much faster build on windows and the windows project compiles a bunch of files at a time. Visual C++ is a much faster compiler than g++. automake and make do not enter into it.

Re: rsync to copy files?

Bob Friesenhahn wrote: I have learned that using 'rsync' to copy files improves the install time quite dramatically for repeat installs. This should only be true when the transfer channel is much slower than the disks on which the files are stored. rsync must read both the source and