Re: portability of xargs

[NightStrike]

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 in that
> almost all rules invoke Cmake to do the work.

> I find that the function of Autoconf is quite useful.  When compared
> with Cmake, it is much more user-friendly since the configure script
> responds to --help and the help output is very helpful.  The configure
> script nicely tells me what it is doing and what it found.  Autotools
> is very structured and projects work in a common way whereas I find
> that Cmake projects are heavily customized with options added by the
> project developer.  Just doing a build entirely outside of the source
> tree is extremely clumsy with Cmake.
>
> Regardless, I don't think that Autotools developers should waste time
> on assuring compatability with systems which are no longer in active
> use.  It is much better so spend time improving areas where Autotools
> is weak.

"Portability" is impossible to quantify.  It expands to far more than
support of ancient, esoteric tools.

I would argue that Cmake is less portable, since it requires that
Cmake be available for a user to build the software.  That can be
onerous, especially if the user doesn't have permission to install
Cmake.  Autoconf requires 'sh', and automake requires 'make'.

I would further argue that Cmake is less portable because it's less
user friendly.  The poor man's distinction is that autotools makes
life for the project owner hard so that the life of the user is easy.
Cmake does the exact opposite, and makes the user's life a difficult
experience so that the developer's life is simpler.  I would
extrapolate that to the realm of "less portable", since it requires
that I have more system requirements in my own brain (skills,
knowledge, experience).  Whereas I can handle any autotools package
trivially with "./configure CFLAGS=-myflag CXX=myC++Compiler
--enable-option --with-package=/custom/path", and know very little
about the upstream project, I can't do so with a Cmake based build
system.

For me, this isn't about 32-year old artifacts.  This is about the
infinitely diverse nature of any modern, still maintained system.  In
a world of corporate policies, shifting environments, environment
modules, embedded devices, cyber security, firewalls, user
permissions, and all sorts of other mitigating factors, all of which I
personally must deal with when trying to deploy any given package to
an environment, I will pick autotools every single time.  The workload
required for me to deploy an autotools package is exponentially
smaller than that required of a Cmake package.

Re: Future plans for Autotools

[NightStrike]

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 which immediately became a lot of "need to support this soon"
> and "wouldn't it be nice" discussion, totally missing the point of the
> text they were reponding to (i.e. "project is on the gurney and may
> expire without help").
>
> Regardless, "baby bird" syndrome seems to be striking a great many
> established free software projects which are mature and heavily used.

I don't think it's fair to expect that a user of autotools is capable
of becoming expert enough in Perl to become a developer of autotools.

> Projects operated by billion dollar companies with teams of developers
> paid to sit in a cubicles and write free sofware seem to be doing
> fine.
>
> Unfortunately, this is not the model for most GNU projects.

I think this is a larger problem with companies tending to put support
into projects with licenses that they find more appealing.  For
instance, IMO, the GPLv3 provoked strong support for billion dollar
companies to latch on to llvm.

There is also a mindset shift with current developers.  The autotools
projects generally were guided by the idea of spreading GNU software
everywhere, and thus they take great care to, first and foremost, make
the job trivial for the person compiling the software at the expense
of more work on the side of the developer; and secondly, to support a
great many systems.  Whereas tools like CMake take a different
approach.  They aim to both support only a few systems
(comparatively), and they aim to make the job of the developer easier
while the job of the person compiling software becomes quite difficult
and cumbersome.

Said more simply, software from earlier days is better for "them",
while software from today is better for "us", for flexible definitions
of "them" and "us".

I don't particularly like the current trend.

Re: Future plans for Autotools

[NightStrike]

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 
> > Fortran (not quite the latest fad) much better.
>
> At our site, there are a number of scripts in use that generate the Fortran
> module/file dependencies on demand. For those not knowing Fortran: source 
> files
> are compiled to both, .mod files for use in runs of the compiler and .o files
> for the later link step. The .mod files can follow a number of conventions in
> respect to suffix and upper/lower case basename and suffix.

This is going to become very important to keep automake relevant, as
c++ is adopting modules using the same two-file-output mechanism as
Fortran. GNU Make supports having a rule generate multiple files and
tracking them accordingly.  I think automake really needs to support
this soon.

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

[NightStrike]

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
>> in Perl and generates an AST so I'll check that.
>>
>
> A Makefile.am file is really just a Makefile with embellishments. It seems
> like your ast would have to incorporate most of make’s syntax to work
> correctly.
>
> The reason Perl was chosen to begin with is because of its great text
> processing capabilities as, ultimately, all automake really does is copy
> the file directly to the output Makefile.in file, filtering out automake
> stuff along the way and injecting make snippets generated from the
automake
> constructs.
>
> This may not appear obvious at first because many simpler Makefile.am
files
> contain only automake stuff. But anything found in the Makefile.am file
> that automake doesn’t recognize is assumed to be proper make script and
> copied directly to the output file.
>
> I suggest making your ast handle non automake chunks as a specific token
> type designed to be passed through without modifications.

I agree that using a coarse grained AST is a good first approach.
Exploration and evaluation of a finer grained approach later during this
GSoC could be interesting too.

Thanks for your input.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

 What problem does the AST solve?

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

[NightStrike]

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
> > doesn't stick out that well, compared to "exampleprog" or something.
> > Also, I personally would suggest it's good if it's obvious from the name
> > what it is, and what it's not. (e.g. Maude could be mistaken as a
> > reference to an actual tool or some technical term the reader might
> > think they have missed) Not saying it needs to be changed, just throwing
> > in another impression.
>
> I changed it from "maude" to "program" in my (unofficial) attempt at
> editing the automake manual:
> http://buildsystem-manual.sourceforge.net/Program-and-
> Library-Variables.html#Program-and-Library-Variables
> I've no current plans to push this rewrite further but maybe someone
> will want to use some parts of it. One of my goals was to remove any
> sense of personality from the documentation so that it was as boring
> as possible, in order to focus on the subject without any
> distractions.
>

I actually found that the lighthearted nature of the automake manual makes
it easier to digest and understand what is otherwise overly dry material.

Re: Should Automake still support Java?

[NightStrike]

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 feels
> outdated since GCJ has been removed from GCC since version 7 and is not
> distributed on recent Debian/Fedora/Ubuntu distributions anymore.
>
>As a consequence, I am considering removing Java support.  Before
> doing that, I would like to consult others, particularly people who may
> still rely on those features.  My questions are the followings:
>
> - Should we remove GCJ support?
> - Should we remove javac support?
> - Should we undeprecate javac support?

Undeprecate, please.

I use automake's java support quite a bit, as I have numerous projects
that are mostly other languages, but that include some java utilities.
It is very nice to manage everything from a single autoconf / automake
setup.  In fact, we picked automake exactly because it supported every
required language.

Please do not remove this support.

> - When should it be done (1.16/1.17/...) ?
>
>If some of you have still access to GCJ, I would be grateful if they
> could help with bug#24895 [1] which can't be adressed otherwise.
>
> Thanks.
>
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24895
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: undeprecate request

[NightStrike]

On Fri, Aug 19, 2016 at 1:15 AM, Václav Haisman  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, 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 both
>> make and ant (or whatever) in the same project.
>>
>
> Does it honestly make sense to integrate Java support into Automake in
> the day and age of Maven and similar better tools?

Given my aforementioned use case, yes.  Automake does a good enough
job that I can easily integrate some java components in an overall
project that uses several different languages.  I wouldn't want to
lose that support.

undeprecate request

[NightStrike]

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 both
make and ant (or whatever) in the same project.

Re: regex bug on arch

[NightStrike]

Thanks!

On Tue, May 10, 2016 at 1:42 AM, Philipp Thomas  wrote:
> * NightStrike (nightstr...@gmail.com) [20160510 04:20]:
>
>
>> 1.15
>
> This has been fixed in git with commit
> 13f00eb4493c217269b76614759e452d8302955e :
>
> diff --git a/bin/automake.in b/bin/automake.in
> index a3a0aa3..2c8f31e 100644
> --- a/bin/automake.in
> +++ b/bin/automake.in
> @@ -3878,7 +3878,7 @@ sub substitute_ac_subst_variables_worker
>  sub substitute_ac_subst_variables
>  {
>my ($text) = @_;
> -  $text =~ s/\${([^ \t=:+{}]+)}/substitute_ac_subst_variables_worker ($1)/ge;
> +  $text =~ s/\$[{]([^ \t=:+{}]+)}/substitute_ac_subst_variables_worker 
> ($1)/ge;
>return $text;
>  }
>
> So either wait for the next release or apply the change to your
> /usr/bin/automake.
>
> hth
> Philipp
>

Re: regex bug on arch

[NightStrike]

1.15
On May 9, 2016 4:38 AM, "Philipp Thomas"  wrote:

> * NightStrike (nightstr...@gmail.com) [20160506 18:50]:
> > With the latest automake on archi linux,
>
> Which is ('automake --version' tells you)?
>
> > 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.
>
>

regex bug on arch

[NightStrike]

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

[NightStrike]

On Fri, Jun 21, 2013 at 8:01 AM, Stefano Lattarini
 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 systems more convenient and manageable
>  (thanks to the new support for the '%reldir%' and '%canon_reldir%'
>  automake-time substitutions).

THANK YOU

Re: make distcheck fails when modules not installed

[NightStrike]

On Sun, Mar 10, 2013 at 10:27 AM, Nate Bargmann  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
> '-module' option and using libltdl for dlopen) installed in pkglibdir.
> Once the package is installed running 'make check' allows the test
> programs to pass.  However, running 'make distcheck' results in a
> failure.
>
> For example:
>
> make[1]: Entering directory `/home/nate/git/hlbld/hamlib-3.0~git/_build'
> make  check-am
> make[2]: Entering directory `/home/nate/git/hlbld/hamlib-3.0~git/_build'
> make  c++/testcpp
> make[3]: Entering directory `/home/nate/git/hlbld/hamlib-3.0~git/_build'
>   CXXc++/testcpp.o
>   CXXLD  c++/testcpp
> make[3]: Leaving directory `/home/nate/git/hlbld/hamlib-3.0~git/_build'
> make  check-TESTS
> make[3]: Entering directory `/home/nate/git/hlbld/hamlib-3.0~git/_build'
> rig:rig_init called
> rig: loading backend dummy
> rig:  lt_dlopen("hamlib-dummy") failed (file not found), trying static 
> symbols...
> rig:  dlsym(initrigs3_dummy) failed 
> (/home/nate/git/hlbld/hamlib-3.0~git/_build/c++/.libs/lt-testcpp: undefined 
> symbol: initrigs3_dummy)
> rig:  lt_dlopen("hamlib-dummy") failed ((null))
> terminate called after throwing an instance of 'RigException'
> /bin/bash: line 5: 17432 Aborted ${dir}$tst
> FAIL: c++/testcpp
> ===
> 1 of 1 test failed
> Please report to hamlib-develo...@lists.sourceforge.net
> ===
> make[3]: *** [check-TESTS] Error 1
> make[3]: Leaving directory `/home/nate/git/hlbld/hamlib-3.0~git/_build'
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory `/home/nate/git/hlbld/hamlib-3.0~git/_build'
> make[1]: *** [check] Error 2
> make[1]: Leaving directory `/home/nate/git/hlbld/hamlib-3.0~git/_build'
> make: *** [distcheck] Error 1
>
>
> If I am guessing correctly, the system linker cannot find the back end
> module in question (in this case 'dummy' which requires no amateur radio
> hardware).  How/where do I specify the directory 'make distcheck' uses?
>
> Here is the Makefile.am fragment for this portion of the library:
>
> lib_LTLIBRARIES += c++/libhamlib++.la
> c___libhamlib___la_SOURCES = c++/rigclass.cc c++/rotclass.cc
> c___libhamlib___la_LDFLAGS = -no-undefined -version-info
> @ABI_VERSION@:@ABI_REVISION@:@ABI_AGE@
> c___libhamlib___la_LIBADD = $(top_builddir)/src/libhamlib.la
>
> check_PROGRAMS += c++/testcpp
> TESTS += c++/testcpp
>
> c___testcpp_SOURCES = c++/testcpp.cc
> c___testcpp_LDADD = c++/libhamlib++.la
> c___testcpp_LDFLAGS = @BACKENDLNK@
> c___testcpp_DEPENDENCIES = c++/libhamlib++.la @BACKENDEPS@
>
>
> In this case testcpp is not able to load the backend.
>
> My Google fu left me with no answers so far.  ;-)

Looks like the link path isn't set right for the test programs

Re: custom silent rule not working in MSYS

[NightStrike]

On Thu, Mar 21, 2013 at 12:29 PM, Vincent Torri  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: $(top_srcdir)/etui.pc.in Makefile
> @rm -f $@
> $(pc_verbose)$(sed_process)
>
> Note that AM_V_GEN is working
>
> Am I doing something wrong ?
>
> thank you
>
> Vincent Torri
>

Does it work not in msys?

Re: Removal of INCLUDES in favour of AM_CPPFLAGS

[NightStrike]

On Fri, Feb 1, 2013 at 4:35 AM, Stefano Lattarini
 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 Automake code base, of course).
>
> So, is anyone using or playing with Automake-NG, or at least
> contemplating the idea to do so in the short term?  Or should
> we just let the project die?

IMO, you should revisit your initial decision to have Automake-NG
instead of Automake-2.0, the latter of which would make having a foot
in both pools far more natural.  Your requirements change in several
ways, including how to handle the upgrade path between the two.  You
could also just blanketly deprecate everything non-gnu in
automake-2.0.

Because honestly... if you proceed with Automake-NG, will there ever
be a mainline 2.0?  Or will it just eventually die anyway?

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

[NightStrike]

On Fri, Dec 21, 2012 at 12:28 PM, David Boesner  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 would like to either create a shared object without the la
> file or delete the
> la file after creating the .so file.
>
> I try it this way:
>
> pamlibdir = $(PAM_DEST_DIR)
> pamlib_LTLIBRARIES = my_module.la
>
> my_module_la_SOURCES = ./src/pam_mypam.c
> my_module_la_LDFLAGS = -module -avoid-version -shared -export-dynamic
> -ltspi -lpam --as-needed --disable-static
> my_module_la_CFLAGS= -Wall -Werror -Wextra
>
> Could you please help me?
>
> Merry X-Mas and a happy new year to everyone.
>
> Regards
>
> David

Have you found a solution to this?  I'd like to do the same thing with
the GCC builds.  When we build with a sysroot, we get lots of
improperly placed la files around that we have to manually remove from
the toolchain.  It'd be fantastic if there was an automatic way to do
that.

Re: AM_CFLAGS no longer in the manual

[NightStrike]

On Sun, Dec 9, 2012 at 10:44 AM, Diego Elio Pettenò
 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 the manual say that AM_CFLAGS is
>> "-g -O2" by default.
>
> Is it? I was confident that AM_CFLAGS is unset by default, but CFLAGS
> (from autoconf) is "-g -O2" by default.
>
> And no you shouldn't change CFLAGS in configure.ac, please. That's an
> user-assignable variable, distributions cry every time that we have to
> patch a CFLAGS="$something" in configure.ac. Especially when that's to
> set/unset -O and -g flags depending on a debug/release build (hint:
> distributions want debug information with optimized builds as well!).

Obviously I'm wrong about the default.  All the more reason that it
should be documented what the default is :)

AM_CFLAGS no longer in the manual

[NightStrike]

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 used, in preference to the per-executable
(or per-library) _CFLAGS.



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 the manual say that AM_CFLAGS is
"-g -O2" by default.

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

[NightStrike]

On Tue, Nov 20, 2012 at 5:25 AM, Bob Friesenhahn
 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 that feature on.
>
>
> Yes, it would be good to have a syntax which tells Automake to perform path
> substitutions based on the relative path of the Makefile include fragment.
> Otherwise Automake would operate as it does now. This syntax would allow
> subdirectories to be moved around without needing the modify the Makefile
> include fragments.  Existing recursive per-subdirectory Makefile.am files
> should be easily updateable to work with a non-recursive build.  In fact, it
> may be that the updated per-subdirectory Makefile.am files could still be
> used to support a recursive configuration depending on how they are used.
>
> I believe that I proposed a syntax on this list in late 2003 or early 2004.
> Perhaps my posting can be found in a mail archive somewhere.

Can you add this feature to automake?

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

[NightStrike]

On Sat, Nov 17, 2012 at 12:13 AM, Václav Zeman  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
> recommendations?

http://mingw-w64.sf.net

Specifically, the mingw-w64-crt sub project.  It's completely non-recursive.

The only thing you really have to watch out for with non-recursive
automake is that all source file references have to be from the top of
your source directory.  For instance, say you have this:

src/Makefile.am
src/file1.c
src/file2.c
src/more/Makefile.am
src/more/file3.c
src/more/file4.c

If you include src/more/Makefile.am into src/Makefile.am (a perfectly
valid thing to do), you will be unpleasantly surprised that
src/more/Makefile.am has to actually know where it is in the source
tree.  It needs lines like this:

prog_SOURCES += more/file3.c more/file4.c

and **NOT** this:

prog_SOURCES += file3.c file4.c


It's really annoying.  It means that renaming a directory is reaaly hard.

Re: How Do Parallel Builds Scale?

[NightStrike]

On Sat, Nov 17, 2012 at 7:30 AM, Bob Friesenhahn
 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 Automake, but
> they use it in a very inefficient way.  Here is a web page which shows the
> current pitiful state of parallel builds:
>
>   http://hubble.gforge.inria.fr/parallel-builds.html
>
> Given that even desktop and laptop computers support 4 CPU cores and that
> affordable server type hardware is available with as many as 64 CPU cores,
> it is useful if the build process of packages is redone so that it benefits
> from compilation on modern hardware.

http://mingw-w64.sf.net/ makes excessive use of massive parallelism.
In fact, we can build every single file in parallel, thanks to a
strong focus on non-recursive make.  At one point in our build
process, we have to build several thousand libX.a files from
corresponding X.def files.  This can be parallelized down to 1 job per
library.

Re: Splitting "make check" into separate build and run targets

[NightStrike]

On Fri, Nov 16, 2012 at 2:38 AM, Björn Stenberg  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 check" on
>> the embedded target.  Or am I missing something?
>
> The "check" target depends on the test programs, which in turn depend on 
> their source code files.
>
> I want to install only the test programs and test data on target, leaving out 
> the the source and object files. That's why I created a "run" target that 
> does not depend on those files being present.

make check-TESTS should suffice to do the actual running of the tests, no?

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

[NightStrike]

On Wed, Oct 17, 2012 at 11:27 AM, Gary V. Vaughan  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 there is a still strong technical argument supporting it that
> I've yet to hear.

One guy and one day isn't really all around.  You should solicit a bit
more feedback (unless there's a bunch of messages that aren't cross
posted to the automake list, so I missed them..)

I, for one, think it's a great idea.

Re: help to create automake

[NightStrike]

On Wed, Oct 3, 2012 at 12:56 PM, Ralf Corsepius  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
>> wildcards, or we have any shorter way?
>
>
> Yes, but where is the problem? You can easily escape to using a script for
> this.

The problem is that this is a feature request that comes up far too
often to be continually ignored, and despite the one-size-fits-all
mentality, there *are* instances where it's a good way to do business.

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

[NightStrike]

On Fri, Jul 27, 2012 at 9:39 AM, Vincent Torri  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
> ...
> ...
> install-data-hook:
> rm -f $(libdir)/$(lib_LTLIBRARIES)
>
> When I cross compile on linux, no problem. When I compile on Windows,
> using MSYS, the .la file is still copied. Here is the output:
>
> make[5]: Entering directory `/home/torri/svnroot/evil/src/lib'
> rm -f /opt/efl/lib/libevil.la
> make[5]: Leaving directory `/home/torri/svnroot/evil/src/lib'
> libtool: install:  chmod a+x /opt/efl/lib/../bin/libevil-1.dll
> libtool: install:  if test -n '' && test -n 'strip --strip-unneeded';
> then eval 'strip --strip-unneeded /opt/efl/lib/../bin/libevil-1.dll'
> || exit 0; fi
> libtool: install: /bin/install -c .libs/libevil.lai /opt/efl/lib/libevil.la
> libtool: install: /bin/install -c .libs/libevil.a /opt/efl/lib/libevil.a
> libtool: install: chmod 644 /opt/efl/lib/libevil.a
> libtool: install: ranlib /opt/efl/lib/libevil.a
>
> One solution (I think) is to move that rule in the top level
> directory, for example, but I'm surprised with the behavior.
>
> I'm not sure that my question is for automake or libtool ML. If
> necessary, I'll transfert the mail to the libtool ML.
>
> versions I have:
>
> automake 1.11.1
> libtool 2.4
>
> Does someone have an idea of the problem ?
>
> thank you
>
> Vincent Torri
>

What version of make?  Last I used msys make, it was a very old, buggy version.

AC_CANONICAL_* and automake variables

[NightStrike]

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?  Why does automake create redundant
variables?

Re: How to use BUILT_SOURCES ?

[NightStrike]

On Thu, Jun 21, 2012 at 7:20 AM, Timothy Madden  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
> code_formatter_SOURCES=code-formatter-parser.yy code-formatter-lexer.ll\
> code-formatter.cc
>
> I can use autoreconf, automake and ./configure sucessfully, but when trying
> to make I get:
>
> [adrian@adrian code-formatter]$ make
> make: *** No rule to make target `position.hh', needed by `all'.  Stop.
>
>
> The file in question is meant to be generated by yacc from
> code-formatter-parser.cc. I thought automake should know that files listed
> in BUILT_SOURCES are meant to be generated, so it should not expect to find
> them there already before the build. Is there something I need to do to fix
> this ?
>
> Thank you,
> Timothy Madden
>
>

Things in built_sources are simply made to be prereqs of the all:
target.  You still have to make rules for them.

If you want yacc support from automake, try reading this:
http://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html

Re: compiling different files with different C compilers

[NightStrike]

On Thu, Jun 7, 2012 at 12:35 PM, Vincent Torri  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 achieve that in Makefile.am ?
>
> Also, in configure.ac, which macro should I use ?  AC_PROG_CC ? 
> AC_PROG_CC_C99 ?
>
> thank you
>
> Vincent Torri
>

Can you just pass different CFLAGS, -std=c89, -std=c99?

Re: dealing with executable shell scripts

[NightStrike]

On Thu, Mar 22, 2012 at 4:00 AM, Miles Bader  wrote:
> Russ Allbery  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 every package with a configure script rely on this?  I suppose
>> that people could chmod +x the configure script before running it, but
>> I've never had to do that.
>
> You can just do "sh configure"... (and I think autoconf/automake are
> careful to never rely on the execute bits of helper scripts being
> set).
>
> Anyway, it's not really the same issue.  "configure" is either part of
> an official distribution tarball (which is a relatively controlled
> environment) or explicitly built (where the build process can arrange
> for the execute bit to be set if appropriate).
>
> The shell-scripts in question, however, are source files, and so come
> directly via whatever mechanism you use to get source files -- tar,
> cp, random-vcs-xyz,   In many cases such mechanisms can preserve
> execute bits, but ... it doesn't feel quite right to rely on that
> always being the case

You aren't preserving anything in the example in your original post.
You are explicitly setting the execute bits for the installed script.
Putting anything in xxx_SCRIPTS does the same thing -- automake will
ensure that they are set execute with $(INSTALL).

You are now saying that you want the source distribution to contain
files with execute permissions, but you still haven't explained how
you were doing that in your original example.

Your original example was copying myprog.sh to myprog and setting the
execute bits for myprog.  That does nothing to guarantee that
myprog.sh also has execute bits in your source distribution.

Removing the useless duplication of myprog.sh > myprog doesn't change
any of that.

Re: dealing with executable shell scripts

[NightStrike]

On Tue, Mar 20, 2012 at 9:06 PM, Miles Bader  wrote:
> 2012年3月21日13:13 NightStrike :
>> 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 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...]

$(INSTALL) will take care of that, but that's not the permissions of
the script in the source code directory, which is what you asked
about.

Re: dealing with executable shell scripts

[NightStrike]

On Tue, Mar 20, 2012 at 5:11 PM, Miles Bader  wrote:
> 2012年3月21日9:32 NightStrike :
>>>> 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
>> illustrating that you don't need to morph from source to script if the
>> file doesn't actually get changed.
>
> Is there a way to ensure that the raw "aaa" is executable in the
> source directory (I'd like everything to be usable whether installed
> or not).

make dist should preserve whatever permissions are there in your
sources.  Your version control software should be able to preserve
permissions, too.  For instance, for svn, you can set the svn:execute
property.  When installing, $INSTALL will automatically set the
permissions accordingly for the SCRIPTS primary.

Here's a better question.  How do you insure that your current file is
executable?  Do it the same way.

Re: dealing with executable shell scripts

[NightStrike]

On Tue, Mar 20, 2012 at 3:16 PM, Bob Friesenhahn
 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.
>
>
> How will Microsoft Windows File Manager and KDE's Dolphin know how to open
> the proper program for the file if the file lacks a proper file extension?

1) You can set the extension to whatever you want.  You're missing the
point that it doesn't have to be renamed on install.
2) I highly doubt windows is in the picture for supporting executing a
borne script.

Re: dealing with executable shell scripts

[NightStrike]

On Tue, Mar 20, 2012 at 1:55 PM, Miles Bader  wrote:
> 2012年3月21日8:33 NightStrike :
>>> "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.  Indeed, doing what I
>>
>> You can avoid hacking EXTRA_DIST if you change your primary from:
>>
>> bin_SCRIPTS = aaa
>> to:
>> 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
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

[NightStrike]

On Mon, Mar 19, 2012 at 3:18 PM, Miles Bader  wrote:
> Harlan Stenn  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 rules to handle all the actual work, need
> to fiddle with EXTRA_DIST and CLEANFILES, etc.  Indeed, doing what I

You can avoid hacking EXTRA_DIST if you change your primary from:

bin_SCRIPTS = aaa

to:

dist_bin_SCRIPTS = aaa

Re: Automake 1.11.2b test release

[NightStrike]

On Thu, Jan 26, 2012 at 1:47 AM, Ralf Corsepius
 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 that politliness prohibits me
> to furtherly comment on this.

Seconded.

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

[NightStrike]

On Wed, Jan 18, 2012 at 8:49 PM, Miles Bader  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.  For packaging, you can use the "dist-hook:"
> rule.

CLEANFILES = ...
EXTRA_DIST = 

I even put wildcards in there:

EXTRA_DIST = dirForUserContrib/*

Re: CFLAGS per source

[NightStrike]

On Sun, Oct 23, 2011 at 2:12 PM, Stefano Lattarini
 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...@gnu.org), so that we won't forget
> about the issue.

What constitutes a proper mail?  Can I just forward my original message?

This just points to generic bug reporting resources:
http://www.gnu.org/software/automake/manual/html_node/Reporting-Bugs.html

>  And of course, patches welcome ;-)

I'd love to, but the FSF makes that a problem.  There really should be
a way to make anonymous contributions.

Re: CFLAGS per source

[NightStrike]

Ping

On Tue, Oct 18, 2011 at 10:49 AM, NightStrike  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.  What if I have multiple sources that are compiled
> differently?
>
> bin_PROGRAMS = a
> a_SOURCES = x.c y.c
>
> I want x.c compiled with -Option1 and y.c compiled with -Option2.
>
> Section 27.8 of the manual, "Per-Object Flags Emulation", describes a
> way to accomplish this using libraries, but is that really the ideal
> solution?  It seems like a very hacky solution compared to supporting
> some syntax for, say, x_c_CFLAGS variables (or something that works
> with sources used multiple times.. perhaps a_x_c_CFLAGS), as in my
> example above.  That would be much cleaner, I would think, compared to
> requiring the user to create and link against useless intermediate
> libraries.
>
> Can this be considered for automake 1.12?
>
> Also, has anyone verified that there really is no difference between
> adding additional .o's to the link and .a's containing those .o's?
> For instance, how does this interact with LTO (link time
> optimization)?

CFLAGS per source

[NightStrike]

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
a_SOURCES = x.c y.c

I want x.c compiled with -Option1 and y.c compiled with -Option2.

Section 27.8 of the manual, "Per-Object Flags Emulation", describes a
way to accomplish this using libraries, but is that really the ideal
solution?  It seems like a very hacky solution compared to supporting
some syntax for, say, x_c_CFLAGS variables (or something that works
with sources used multiple times.. perhaps a_x_c_CFLAGS), as in my
example above.  That would be much cleaner, I would think, compared to
requiring the user to create and link against useless intermediate
libraries.

Can this be considered for automake 1.12?

Also, has anyone verified that there really is no difference between
adding additional .o's to the link and .a's containing those .o's?
For instance, how does this interact with LTO (link time
optimization)?

Re: bug#9088: Java support

[NightStrike]

On Wed, Jul 20, 2011 at 1:04 AM, tsuna  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 listed
as prerequisites, $? will list all the ones newer than the target.
So, automake could easily write a rule to run the compiler against
only the .java files that have changed.

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

[NightStrike]

On Tue, Mar 29, 2011 at 2:53 AM, Stefano Lattarini
 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 Automake-generated
>> >>    Makefiles to exploit more features of GNU make.  The exact details
>> >>    of how and on what level this is to be implemented (e.g., at Automake
>> >>    time by the developer, at configure time by the user, or a mixture of
>> >>    both) is to be determined in the design phase of the project.
>> >>
>> > I've now submitted my application to the GSoC site:
>> >   
>> > 
>> >
>> > Regards,
>> >    Stefano
>> >
>> >
>> I get:
>>
>> ===
>> Error: Server Error
>> The server encountered an error and could not complete your request.
>>
>> If the problem persists, please report your problem and mention this error
>> message and the query that caused it.
>> 
>>
>>
> Weird, I can load the page even without being logged in (I made the proposal
> publicly visible, and tried with success to look at the page both yesterday
> and right now).
>
> Is anyone else experiencing problems?
>
> Regards,
>  Stefano
>
>

Works fine for me

Re: GSoC project idea: non-recursive automake project

[NightStrike]

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 :) :) :)

Re: GSoC project idea: non-recursive automake project

[NightStrike]

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-mentor and work with them to convert NTP to that sort of operation.
>>
>> It's mostly trivial. How hard are GSoC projects supposed to be?
>
> I'll assume you have seen my reply to Ralf.
>
> From my POV, I have heard folks saying for a long time how "easy" it is
> to use automake to produce non-recursive Makefiles.  But I haven't seen
> this in practice, and on the (few) attempts I have made to figure it out
> myself and look for examples, I have not yet been able to find a really
> useful solution.

A solution to *what* exactly?  Said another way, what *exactly* is the
problem with automake+non-recursion that you would want solved?

I personally have found that the only obstacle to me is minor -- all
sources have to be specified relative to the top level directory, even
in a subdir Makefile fragment that gets included in the top.

> What I think we'd want is a reasonably well-documented description of
> how to use automake to produce a source tree where one can:
>
> - run "make" from the top-level of the tree and all of the normal things
>  happen (and all of the normal targets work)
> - run "make" from a subdir, which would handle all of the normal targets
>  for that subdir, and would also automatically handle *all* of the
>  dependencies needed for the specified targets in that subdir (like
>  prerequisite libraries).

Re: Test support for automake

[NightStrike]

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 support for automake
>>
>> I have a non-recursive Makefile.am with which I build a library foo. I
>> list all my tests (quite a lot) in check_PROGRAMS.
>>
>> All those tests should (of course) get libfoo.la as LDADD, but how
>> exactly do I do that _without_ doing a per-target *_LDADD specification.
>> Per target specification sounds like a lot of redundancy since all my
>> _LDADD specification would just be libfoo.la.
>> I'd like to add libfoo.la in only _one_ place.
>>
>> Ralf
>
> Use the LDADD variable.  It's similar to the AM_* variables e.g. AM_LDFLAGS, 
> AM_CPPFLAGS.  All programs use LDADD for linking unless it is overridden by a 
> maude_LDADD per-target variable.
>
> See http://sources.redhat.com/automake/automake.html#Linking
>
> Jeff
>
>
>
>

It sounds like this is a good use case for support of check_LDADD,
which of course is going to imply a request for generic x_Y support,
where x is any prefix (bin, lib, etc) and Y is any suffix (cflags,
etc).

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

[NightStrike]

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 instance, and it's the
biggest public project that I personally know about.  I worked on a
250ksloc project, but that was in Java and just used eclipse native
stuff (not even ant).  I worked on a 1m sloc project in ada... but for
that project, every build was a full complete 100% fresh build for
reasons outside of this thread.

At what magnitude does make break down, do you think?  And how/where
does it become flawed?

In retrospect, even when dealing with GCC, I never do a partial
rebuild.  Every patch for me no matter how simple involves a complete
fresh build (and because of the nature of what I do with GCC, that
also involves a complete fresh build of binutils and of our libc).  So
I really don't have any good context from which to extrapolate your
meaning.

Re: Automake and AR

[NightStrike]

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 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
>> >>>>>>>> expect.
>> >>>>>>>>
>> >>>>>>>> Is this an automake bug, or user error?
>> >>>>>>>
>> >>>>>>> Looks like an automake bug to me.  Just putting
>> >>>>>>>  AC_CHECK_TOOL([AR], [ar], [false])
>> >>>>>>>
>> >>>>>>> somewhere in configure.ac should serve as a workaround though.
>> >>>>>>>
>> >>>>>>> Thanks for the report, will fix,
>> >>>>>>> Ralf
>> >>>>>>
>> >>>>>> Was this ever fixed?  What version of automake will it be in?
>
>> >>>>> Ping
>> >>>> Ping
>> >>> Ping x3 :)
>> >> Ping x4
>
> Just so you know why I haven't followed up on this so far:
> We pointed out a very simple one-line workaround that you can use.

You also said "Thanks for the report, will fix."

> That makes fixing this bug fairly low priority.

> Also, it will be fixed as a side effect of AM_PROG_AR eventually,
> I suppose.

I don't know what you mean by "as a side effect."  Will it be in the
next version of automake, because other work is going on in
AM_PROG_AR?

Re: Automake and AR

[NightStrike]

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:
>>>>> 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
>>>>>>>> from, but I do know that it's definitely not $host-ar, as I would
>>>>>>>> expect.
>>>>>>>>
>>>>>>>> Is this an automake bug, or user error?
>>>>>>>
>>>>>>> Looks like an automake bug to me.  Just putting
>>>>>>>  AC_CHECK_TOOL([AR], [ar], [false])
>>>>>>>
>>>>>>> somewhere in configure.ac should serve as a workaround though.
>>>>>>>
>>>>>>> Thanks for the report, will fix,
>>>>>>> Ralf
>>>>>>>
>>>>>>
>>>>>> Was this ever fixed?  What version of automake will it be in?
>>>>>>
>>>>>
>>>>> Ping
>>>>>
>>>>
>>>> Ping
>>>>
>>>
>>> Ping x3 :)
>>>
>>
>> Ping x4
>
> Just a silly question since nothing else is happening, do you even have
> $host-ar somewhere on your path?
>
> Cheers,
> Peter
>
>

Yes.  The full cross compiler is in the PATH.  This is shown in that
the AC_CHECK_TOOL version works.

Re: Automake and AR

[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:
>>> 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
>>>>>> from, but I do know that it's definitely not $host-ar, as I would
>>>>>> expect.
>>>>>>
>>>>>> Is this an automake bug, or user error?
>>>>>
>>>>> Looks like an automake bug to me.  Just putting
>>>>>  AC_CHECK_TOOL([AR], [ar], [false])
>>>>>
>>>>> somewhere in configure.ac should serve as a workaround though.
>>>>>
>>>>> Thanks for the report, will fix,
>>>>> Ralf
>>>>>
>>>>
>>>> Was this ever fixed?  What version of automake will it be in?
>>>>
>>>
>>> Ping
>>>
>>
>> Ping
>>
>
> Ping x3 :)
>

Ping x4

Re: Automake and AR

[NightStrike]

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 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.
>>>>>
>>>>> Is this an automake bug, or user error?
>>>>
>>>> Looks like an automake bug to me.  Just putting
>>>>  AC_CHECK_TOOL([AR], [ar], [false])
>>>>
>>>> somewhere in configure.ac should serve as a workaround though.
>>>>
>>>> Thanks for the report, will fix,
>>>> Ralf
>>>>
>>>
>>> Was this ever fixed?  What version of automake will it be in?
>>>
>>
>> Ping
>>
>
> Ping
>

Ping x3 :)

Re: Automake and AR

[NightStrike]

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 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?
>>>
>>> Looks like an automake bug to me.  Just putting
>>>  AC_CHECK_TOOL([AR], [ar], [false])
>>>
>>> somewhere in configure.ac should serve as a workaround though.
>>>
>>> Thanks for the report, will fix,
>>> Ralf
>>>
>>
>> Was this ever fixed?  What version of automake will it be in?
>>
>
> Ping
>

Ping

Re: Automake and AR

[NightStrike]

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
>>> from, but I do know that it's definitely not $host-ar, as I would
>>> expect.
>>>
>>> Is this an automake bug, or user error?
>>
>> Looks like an automake bug to me.  Just putting
>>  AC_CHECK_TOOL([AR], [ar], [false])
>>
>> somewhere in configure.ac should serve as a workaround though.
>>
>> Thanks for the report, will fix,
>> Ralf
>>
>
> Was this ever fixed?  What version of automake will it be in?
>

Ping

Re: Automake and AR

[NightStrike]

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
>> expect.
>>
>> Is this an automake bug, or user error?
>
> Looks like an automake bug to me.  Just putting
>  AC_CHECK_TOOL([AR], [ar], [false])
>
> somewhere in configure.ac should serve as a workaround though.
>
> Thanks for the report, will fix,
> Ralf
>

Was this ever fixed?  What version of automake will it be in?

Re: check_PROGRAMS & LDADD

[NightStrike]

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
>> ===
>>
>> As the collection of tests grows it's going to get annoying to have to
>> add an _LDADD entry for every single one separately. Is it possible to
>> add an _LDADD for all check_PROGRAMS items in one blow?
>
> All *_PROGRAMS that don't have an *_LDADD override use plain LDADD:
>
> LDADD = -lquark

Is there any _PROGRAM that isn't a check_PROGRAM?

Re: Call for help: Vala support in Automake

[NightStrike]

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: conditionals in Makefile.am

[NightStrike]

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. You may specify an argument to else in which
>> case it must be the negation of the condition used for the current if.
>> Similarly you may specify the condition that is closed on the endif
>> line:
>>
>>      if DEBUG
>>      DBG = debug
>>      else !DEBUG
>>      DBG =
>>      endif !DEBUG
>>
>>
>> What's the purpose of "specifying the condition that is closed"?  I've
>> never seen this kind of construct before.  Is it a substitute for
>> elseif?
>>
>
> Documentation. There may be several dozen lines of code between the if
> and the else. A reader may be wondering... else what?
>
> John
>
>

Does it matter if the endif condition is COND or !COND?

Re: cross-compiling but keeping one target native

[NightStrike]

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: Built-in target to delete all generated files

[NightStrike]

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 how sophisticated of a
>>> VCS you're using.  If you're using CVS, you basically can't do useful
>>> merges anyway without supporting scripts and a bunch of pain, so the
>>> additional merge conflicts from auto-generated files probably aren't
>>> making your life much worse the way that they would in Git.
>
>> I never had an issue using svn on mingw-w64, and we keep
>> configure/makefile.in/etc in the repo.  It's a lot easier to make the
>> developers on your project use the right versions of stuff than imposing
>> that requirement on all of your users.  In my mind, our users should be
>> able to download, configure, compile, and use.  Creating the build
>> system (autoreconfing) shouldn't be their responsibility.
>
> I realize that opinions differ on this, but as far as I'm concerned, at
> the point that you're pulling stuff directly from the VCS, you're not a
> user.  You're a developer.  Users should download official releases, which
> of course have everything already generated.
>
> I think this just varies based on what your developers are like and how
> closed your project is, basically.  People often say that they find it
> fairly easy to make all developers on a project use identical versions of
> the autotools.  I find that sort of mind-boggling, since it would be
> absolutely impossible for the projects that I work on.  People contribute
> to my projects using everything from NetBSD to Solaris, versions of Linux
> from RHEL 4 to Debian unstable, and all sorts of random locally-installed
> versions of stuff.  I usually don't even have exactly the same versions of
> Autoconf and Automake on all the different systems that *I* use to do
> development.
>
> I'm certainly not going to ask people to install some specific version of
> Autoconf before contributing to the build system of my projects.  There
> shouldn't be any need.
>
> --
> Russ Allbery (r...@stanford.edu)             <http://www.eyrie.org/~eagle/>
>
>
>

The tcl project has an interesting solution.  Anyone commits changes
to configure.ac/Makefile.am, and then they ask the people that can do
so to regenerate the other files.  It has holes, of course, but it
works for them :)

As you say, every project has its own needs.

Re: Built-in target to delete all generated files

[NightStrike]

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 they
>> have on their system.
>
> I used to do this, but it quickly turned into a major annoyance.  You get
> all sorts of spurious differences based on what version of the tools
> people regenerating files happened to have installed and then all sorts of
> obnoxious merge conflicts and related problems when trying to integrate
> third-party branches.
>
> I suspect it depends on what sort of activities you expect people using a
> VCS checkout directly to be doing, and also how sophisticated of a VCS
> you're using.  If you're using CVS, you basically can't do useful merges
> anyway without supporting scripts and a bunch of pain, so the additional
> merge conflicts from auto-generated files probably aren't making your life
> much worse the way that they would in Git.

I never had an issue using svn on mingw-w64, and we keep
configure/makefile.in/etc in the repo.  It's a lot easier to make the
developers on your project use the right versions of stuff than
imposing that requirement on all of your users.  In my mind, our users
should be able to download, configure, compile, and use.  Creating the
build system (autoreconfing) shouldn't be their responsibility.

Re: GNU autogen code generation

[NightStrike]

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 should use the information
> in it to find the template file and to produce the result by performing
> expansions in the template file.
> The extension of the result is defined in the template file and it can
> be whatever, either one file, or more files that differ in extensions
> (like a C source file and a header).
>
> What I would like to have is some integration of autogen with autoconf
> like YACC and LEX have.
> Which means that I would like to specify the template and definitions
> file in _SOURCES variable and Automake could take care of the rest:
>        - Generating intermediate sources
>        - Compiling those sources
>        - Distributing both autogen sources (= templates and definitions) and
> intermediate sources so even users who don't have autogen installed can
> compile the source.
> So i have some questions:
>        - Wouldn't it be worth to have an AM_PROG_AUTOGEN macro since autogen
> is GNU software?
>        - If not, is there a way how to easily achieve similar functionality
> using current automake capabilities?
>
> For example if I know that every file foo.def and foo.tpl pair results
> in foo.c, maybe I could have the following rule in Makefile.am:
> .def.c: $(basename $<).tpl
>        $(autogen) autogen -o $@ $<
> (just a guess)
> But how to settle the distribution problem? I would probably need to put
> foo1.c foo2.c to something_SOURCES
> and
> foo1.tpl foo1.def ... ... to EXTRA_DIST
> but one would like to have those tpls and defs in SOURCES and the rest
> generated automatically, like for YACC and LEX.
> What do you think?

Someone will probably correct me, but you could try putting those
sources that you are building into BUILT_SOURCES.

>
> As a side note, I was thinking about generating code using m4 and some
> macro package, and since it is not so uncommon to generate code, I would
> like to ask what is the good approach to this since the automake manual
> doesn't tell very much about this...
> Regards,
> Matej
>
>
>
>

Re: Teaching automake about dll defs

[NightStrike]

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 many other things) is that
>> >> it lets automake handle figuring out dependencies.  In my example,
>> >> libx.a doesn't depend on x.def, and I don't know how to make it do so.
>> >>
>> >
>> > Ping
>> >
>>
>> x2
>
> From me, the answer is no.  There are lots of other things that are more
> important to a presumably larger user base, that are more portably
> usable in principle, and IIUC you can easily work around the current
> limitation.

Well.. not nicely.  It's kind of ugly, and doesn't do anything about
dependency tracking.

> If somebody else codes it, I might consider it, but even then it'd be
> strictly lower priority than basically all other pending stuff I know
> of, both with and without patches.

Ouch :(

> Sorry,
> Ralf
>

Re: Regarding the JAVA primary

[NightStrike]

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 functionality would come -- perhaps a java utility, so that the same
> level of portability would be available to java builds as the source that's
> being built. That is, if someone uses the JAVA primary, he/she can expect to
> be required to have additional build functionality available, in the form of
> a JVM and javac compiler. Just a thought.

You can resolve the globbing spec at automake time instead of make
time.  That way, Makefile.in still contains a static list.

If you went this route, I'd be curious how quickly someone ports it to
other primaries :)

Re: Teaching automake about dll defs

[NightStrike]

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 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 noticed that the --def option isn't documented, that I can see.
>>> Maybe there's a newer option that I'm supposed to use (oops), but
>>> that's the general idea.  You do this right before AR and RANLIB.
>>> What I do currently in my makefile is to override AR:
>>>
>>> lib64_libksuser_a_AR = $(DTLIB) -m i386:x86-64 --as-flags=--64; $(AR) 
>>> $(ARFLAGS)
>>>
>>> Where DTLIB is:
>>> DTDEF=$(DLLTOOL) $(AM_DLLTOOLFLAGS) --def
>>> DTLIB=$(DTDEF) $(top_srcdir)/`echo $@ | $(SED) 's|/lib|/|;s|\.a|.def|'`
>>> AM_DLLTOOLFLAGS=$(dlltool_underscores) -k --as=$(AS) --output-lib $@
>>>
>>> It seems like this could easily be handled by automake, though, if it
>>> detected a .def file in the sources list (much like how it knows how
>>> to handle .S for asm, for example).
>>>
>>> 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 handle figuring out dependencies.  In my example,
>> libx.a doesn't depend on x.def, and I don't know how to make it do so.
>>
>
> Ping
>

x2

Re: Teaching automake about dll defs

[NightStrike]

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 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 noticed that the --def option isn't documented, that I can see.
>> Maybe there's a newer option that I'm supposed to use (oops), but
>> that's the general idea.  You do this right before AR and RANLIB.
>> What I do currently in my makefile is to override AR:
>>
>> lib64_libksuser_a_AR = $(DTLIB) -m i386:x86-64 --as-flags=--64; $(AR) 
>> $(ARFLAGS)
>>
>> Where DTLIB is:
>> DTDEF=$(DLLTOOL) $(AM_DLLTOOLFLAGS) --def
>> DTLIB=$(DTDEF) $(top_srcdir)/`echo $@ | $(SED) 's|/lib|/|;s|\.a|.def|'`
>> AM_DLLTOOLFLAGS=$(dlltool_underscores) -k --as=$(AS) --output-lib $@
>>
>> It seems like this could easily be handled by automake, though, if it
>> detected a .def file in the sources list (much like how it knows how
>> to handle .S for asm, for example).
>>
>> 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 handle figuring out dependencies.  In my example,
> libx.a doesn't depend on x.def, and I don't know how to make it do so.
>

Ping

Re: Teaching automake about dll defs

[NightStrike]

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 --as=$triplet-as --output-lib=libx.a --def=x.def
> --as-flags=$(ASFLAGS)
>
> I noticed that the --def option isn't documented, that I can see.
> Maybe there's a newer option that I'm supposed to use (oops), but
> that's the general idea.  You do this right before AR and RANLIB.
> What I do currently in my makefile is to override AR:
>
> lib64_libksuser_a_AR = $(DTLIB) -m i386:x86-64 --as-flags=--64; $(AR) 
> $(ARFLAGS)
>
> Where DTLIB is:
> DTDEF=$(DLLTOOL) $(AM_DLLTOOLFLAGS) --def
> DTLIB=$(DTDEF) $(top_srcdir)/`echo $@ | $(SED) 's|/lib|/|;s|\.a|.def|'`
> AM_DLLTOOLFLAGS=$(dlltool_underscores) -k --as=$(AS) --output-lib $@
>
> It seems like this could easily be handled by automake, though, if it
> detected a .def file in the sources list (much like how it knows how
> to handle .S for asm, for example).
>
> 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 handle figuring out dependencies.  In my example,
libx.a doesn't depend on x.def, and I don't know how to make it do so.

Teaching automake about dll defs

[NightStrike]

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 noticed that the --def option isn't documented, that I can see.
Maybe there's a newer option that I'm supposed to use (oops), but
that's the general idea.  You do this right before AR and RANLIB.
What I do currently in my makefile is to override AR:

lib64_libksuser_a_AR = $(DTLIB) -m i386:x86-64 --as-flags=--64; $(AR) $(ARFLAGS)

Where DTLIB is:
DTDEF=$(DLLTOOL) $(AM_DLLTOOLFLAGS) --def
DTLIB=$(DTDEF) $(top_srcdir)/`echo $@ | $(SED) 's|/lib|/|;s|\.a|.def|'`
AM_DLLTOOLFLAGS=$(dlltool_underscores) -k --as=$(AS) --output-lib $@

It seems like this could easily be handled by automake, though, if it
detected a .def file in the sources list (much like how it knows how
to handle .S for asm, for example).

Is this possible?  Is there anyone willing to do it?

Re: Custom make rules yield ambiguous result

[NightStrike]

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 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 lib64/libmsvcrt.a lib64/libmsvcr80.a: lib64/lib%.a: 
>> lib64/%.def
>>         $(DTDEF) $< --dllname $*.dll -m i386:x86-64 --as-flags=--64
>>
>> lib64/lib%.a: lib64/%.def
>>       $(DTDEF) $< -m i386:x86-64 --as-flags=--64
>>
>>
>> What I noticed is happening is that those three files, libcrtdll.a,
>> libmsvcrt.a, and libmsvcr80.a, are being built using the second rule
>> instead of the first, and so they don't contain the rather crucial
>> --dllname option.
>
> automake should be copying those rules into the resulting makefile
> without any change (except a @LIB32_TRUE@ prefix which expands to empty
> if the conditional is true).  So, the remaining issue should be purely
> between GNU make and the file.  Looking at the file closely shows that
> the first rule doesn't start its command with a TAB.
>
> Cheers,
> Ralf
>

Ralf, as always, you're a genius.  I replaced the spaces with a tab
for that line, and it all works as it should.  Reading up on it, I see
now that make requires the commands of a target to be indented with a
space.  I didn't realize that before.

As always, thank you kindly!

Custom make rules yield ambiguous result

[NightStrike]

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 lib64/libmsvcrt.a lib64/libmsvcr80.a: lib64/lib%.a:
lib64/%.def
$(DTDEF) $< --dllname $*.dll -m i386:x86-64 --as-flags=--64

lib64/lib%.a: lib64/%.def
$(DTDEF) $< -m i386:x86-64 --as-flags=--64


What I noticed is happening is that those three files, libcrtdll.a,
libmsvcrt.a, and libmsvcr80.a, are being built using the second rule
instead of the first, and so they don't contain the rather crucial
--dllname option.

What can I do about this?

Re: Sun compiler and /usr/local/include

[NightStrike]

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/compiler
>>  > automatically supplies -I/usr/local/include (for example, g++ does, but
>> sun
>>  > CC does not), and if not, how to add it to some CFLAGS variable?
>>
>> To expand on a point Ralf touched on, the typical Autoconf approach is
>> to predict as little as possible, and test for exactly what you need.
>> So I would ask you, when your package in built with Sun cc and fails
>> for lack of -I/usr/local/include, which header file in
>> /usr/local/include causes the break?  It should be in the compiler's
>> error message.  And I would suggest you then consider using a
>> configure.ac test for that specific header file, assuming your code
>> #includes it, or for the header file your project #includes which
>> triggers the inclusion of the wrong/missing header.  That test would
>> then result in the addition of -I/usr/local/include on your Sun cc
>> configuration.  At the same time, you could easily expand it later if
>> another system has that header file in a different directory, by
>> searching a list of directories for the needed .h, rather than simply
>> /usr/local/include.
>>
>> Instead of "my project needs -I/foo/include on system bar", I suggest
>> "my project needs to find the correct foo.h on all systems".
>>
>
> If the file is; /usr/local/include/package/header.h
> and source is;  #include 
> what goes in configure.ac?
>
> AC_CHECK_HEADER([package/header.h]) just says 'no'.

Something like this would error out if the header isn't found:
AC_CHECK_HEADER([package/header.h],[],[AC_MSG_ERROR([header.h not
found but required])])

Re: unconditional version of EXTRA_DIST

[NightStrike]

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,
>>    EXTRA_DIST = pattern*
>>
>> - automake conditionals,
>>    if COND
>>    EXTRA_DIST += files...
>>    endif
>>
>> - or plain old configure substitutions for variable content in
>> EXTRA_DIST.
>>    EXTRA_DIST = file @list_of_files@ $(more_files)
>
> ok,thanks. will try wildcard.
> "*html" as patter will also work, if there is not even a single
> html file?
>
> Andreas
>
>
>

If the wildcard doesn't match, I'm pretty sure you get some kind of
error trying to find a file called "*html".

Re: AM_PROG_AS

[NightStrike]

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 does not set AS.  This macro is 10 lines long, you could
> easily have verified that by looking at it.

Sorry, but I'm not that smart :(

I said that it "seems" to, since I just kept removing macros until AS
stopped being defined.  Maybe I put "dnl" on the wrong line and thus
drew the wrong conclusion.  Maybe I don't even need AS.  Do you know
if I can pass in the $(CCAS) that AM_PROG_AS sets according to the
manual into dlltool's --as option?  If CCAS is just set to gcc, will
dlltool be able to handle that?  Or is this getting just way too far
off topic, and I should just try it myself or go to the binutils list?

Re: Automake and AR

[NightStrike]

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
>> expect.
>>
>> Is this an automake bug, or user error?
>
> Looks like an automake bug to me.  Just putting
>  AC_CHECK_TOOL([AR], [ar], [false])
>
> somewhere in configure.ac should serve as a workaround though.
>
> Thanks for the report, will fix,
> Ralf
>

Thanks!

I am also noting that in this and previous emails, you are
recommending "false" as the third argument.  In the manual, there are
numerous locations that serve as examples that imply a colon is the
proper choice (and thusly it is what I have used).  Which is better?

Re: distcheck and canonical_*

[NightStrike]

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
>> > propagated to configure without explicitly setting
>> > DISTCHECK_CONFIGURE_FLAGS?
>>
>> erm... isn't --host enabling cross-compiling?
>> And when cross-compiling, make check always fails with some
>> "cannot execute binary" or so, so distcheck would always fail?
>
> NightStrike's package is very specialized: by default it will run
> on 64-bit Windows only, because it's part of the support package
> for MinGW64 (or so I assume).  So, since the package already requires
> a cross compilation environment, it might as well also require an
> emulator to be able to execute tests for a successful distcheck.
> wine comes to mind for this, together with binfmt-support to
> automatically execute w32 binaries using wine.

Correct.  And 64-bit Wine actually works pretty well.

AM_PROG_AS

[NightStrike]

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?

Automake and AR

[NightStrike]

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?

Re: Public header files

[NightStrike]

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 to modify both files manually? Another example is that my library
> needs a 64bit integer type for its public api.
>
> Since a config.h header files is not supposed to be public, that's not an
> option. But how can I do this correctly?

BUILT_SOURCES?

Re: distcheck and canonical_*

[NightStrike]

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
>> DISTCHECK_CONFIGURE_FLAGS?
>
> The default INSTALL file recommends just running
>  ./configure
>  make
>  make install
>
> without further options.  The Autoconf manual documents, as basic
> statement, running ./configure without options.  The implicit assumption
> engraved into autotools is that a plain ./configure works "most of the
> time".
>
> As such, distcheck, the test which aims to help ensure that your package
> is suitable for the average user, should just invoke that plain
> configure.  The way you have set up the package in your developer build
> tree may have little to with that, be that --host or
> --enable-maintainer-mode arguments.
>
> So yes, the fact that arguments are not propagated from configure to
> distcheck by default, could be called a feature.
>
> Hope that helps.  If you need --host by default on your system, I
> suggest you install on it a config.site file that sets host_alias;
> if your package needs some settings for distcheck to work by default,
> then you can use DISTCHECK_CONFIGURE_FLAGS.
>
> Cheers,
> Ralf
>

Given that our base system is 64-bit windows, and there is no unixy
environment for it yet (msys is still 32-bit only), we are pretty much
always cross compiling when doing distchecks (usually from linux, as
it's fast).  So, I wound up just putting --host into the distcheck
configure arguments.  Hope that's ok.

distcheck and canonical_*

[NightStrike]

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

[NightStrike]

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 (and maybe
> DIST_SUBDIRS) in the toplevel Makefile.  There is one decision for you
> to make here: should 'make dist' tar up all subpackages, even those that
> aren't build (which is the default, because that's what's right to
> ensure downstream has the same choices as you) in which case you can
> just
>
>  if LIBRARIES_MANGLE
>  SUBDIRS += mingw-w64-libraries/libmangle
>  endif
>  ...

I used the DIST OPTIONS thing to enable all sub packages for
distribution.  See my links below for how I did it (hopefully I chose
a method that's ok)

> In the other case you should use something like
>  AC_SUBST([libmangle_subdir], [mingw-w64-libraries/libmangle])
> and
>
>  SUBDIRS = ... $(libmangle_subdir) ...

Well, I committed it to svn, so everything is available here:
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/Makefile.am?view=markup
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/configure.ac?view=markup

Previously, in the case statements, I had AC_CONFIG_SUBDIRS in each
path.  For instance:

[yes|all],[
   with_libraries="libmangle,pseh"
   with_libraries_mangle=yes
   with_libraries_pseh=yes
   AC_CONFIG_SUBDIRS([mingw-w64-headers/libraries/libmangle])
   AC_CONFIG_SUBDIRS([mingw-w64-headers/libraries/pseh])],
[libmangle],[
   with_libraries="libmangle"
   with_libraries_mangle=yes
   with_libraries_pseh=no
   AC_CONFIG_SUBDIRS([mingw-w64-headers/libraries/libmangle])],
...etc

That tossed an error saying that the directory libmangle was already
in the list of stuff to be configured.

Automake conditionals in autoconf

[NightStrike]

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 building to configure
and build the various trees in the mingw-w64.sf.net project.  Here's
the relevant directory layout:

trunk/
trunk/mingw-w64-libraries
trunk/mingw-w64-libraries/libmangle
trunk/mingw-w64-libraries/pseh

trunk contains the top level configure.ac/makefile.am
mingw-w64-libraries contains just sub directories
libmangle and pseh both contain their own self-contained fully
autotool'd build system

This same thing is replicated across a lot of directories inside
trunk, but I'm guessing once I get one right, I'll get them all.

So I have a top level configure, and I put this in it:

AC_MSG_CHECKING([whether to build the optional libraries])
AC_ARG_WITH([libraries],
  [AS_HELP_STRING([--with-libraries=ARG],
[Build the extra mingw-w64 libs, where ARG is one of libmangle,
pseh, or all])],
  [],
  [with_libraries=no])
AS_CASE([$with_libraries],
  [yes|all],[
with_libraries="libmangle,pseh"
with_libraries_mangle=yes
with_libraries_pseh=yes],
  [libmangle],[
with_libraries="libmangle"
with_libraries_mangle=yes
with_libraries_pseh=no],
  [pseh],[
with_libraries="pseh"
with_libraries_mangle=no
with_libraries_pseh=yes],
  [no],[
with_libraries_mangle=no
with_libraries_pseh=no],
  [AC_MSG_ERROR([Invalid argument to --with-libraries: $with_libraries])])
AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes])
AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes])
AM_COND_IF([LIBRARIES_MANGLE],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/libmangle])])
AM_COND_IF([LIBRARIES_PSEH],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/pseh])])
AC_MSG_RESULT([$with_libraries])


Those two AM_COND_IF lines at the bottom didn't use to be there.
Instead, I had the AC_CONFIG_SUBDIRS lines in each appropriate branch
of the case statement.  However, autoreconf complained that hte macro
was expanded more than once.  Is the way I'm doing this kosher?  Is it
"The Right Way", or is there a better approach?  (for the whole thing,
not just the AM_COND_IF part)

Distributed files: licenses

[NightStrike]

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 source archives,
but I don't see much convention on doing so with binary archives.

Right now, our project (http://mingw-w64.sf.net/) builds and
distributes complete GCC toolchains using our header set and crt.
This includes, of course, building and distributing our own project as
a part of it all.  Should we include license files with that?  We have
received this feature request:
https://sourceforge.net/tracker/?func=detail&atid=983357&aid=2944821&group_id=202880

What is the convention held by the typical project out there?  I know
nothing about licenses, nor how to actually handle them.  All insight
is greatly appreciated.

Re: Non-recursive automake

[NightStrike]

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_SOURCES = foo/one.c foo/two.c
>>
>> Usually I stuff that into a file called "foo/Automakefile" and "include
>> foo/Automakefile" from the real Makefile.am. Despite being in a
>> subdirectory, one may not omit foo/; that is ok.
>>
>> However, it is tiresome. Is there perhaps a way, or a planned
>> development action, so that one can omit all foo/s inside
>> foo/Automakefile and have automake automatically add foo/ upon seeing
>> "include" (or a variant thereof) in the upper Makefile.am?
>
> Yes.  The latest plan I couldn't get stabilized so left out for 1.11:
> 
> It would be a good idea to look at it again, though.

Is this planned for any future automake?

Fortran and flag ordering

[NightStrike]

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
xx_CFLAGS = -O3

yields:

gcc ... -O3 -g -O2 ...
gfortran ... -g -O2 ...

Likewise:

bin_PROGRAMS = xx
xx_SOURCES = a.c a.f95
xx_FCFLAGS = -O3

yields:

gcc ... -g -O2 ...
gfortran ... -O3 -g -O2 ...


Basically, -O2 is omnipresent.  This shouldn't be, if I understand the
manual correctly.

Compiler options checking

[NightStrike]

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

[NightStrike]

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

[NightStrike]

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 TESTS support, as of version 1.11, consists of two different
>> test drivers that run tests from within a makefile.  The old one is
>> pretty minimalistic in test suite functionality, the new one (selected
>> with the `parallel-tests' option) is mostly backward-compatible, but
>> also offers some more and slightly changed functionality.  It still
>> operates as a set of rules within a makefile.
>
> Here is a small tour through the features of the new framework.  I hope
> you don't mind that I just post it here.

Thanks!

Various testsuites

[NightStrike]

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 between two products which are
very inter-related?

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

[NightStrike]

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'.

As I understand it, there are several ways to turn that option on,
only one of which is via AM_INIT_AUTOMAKE.  Can you just use one of
the other methods?

Re: Automake 1.10.2 and color-tests

[NightStrike]

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/automake/Tests.html#Tests
>
> <http://git.savannah.gnu.org/cgit/automake.git/commit/?h=branch-1-10&id=b7563c7444b6aca6656c5edf44e416de130ee52e>
>
> Cheers,
> Ralf
>

Ah.. might want to update the manual that's "official" ?

Automake 1.10.2 and color-tests

[NightStrike]

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 (version 1.10.2, 23 November 2008), a
program that creates GNU standards-compliant Makefiles from template
files."


I am running automake 1.10.2:

$ automake --version
automake (GNU automake) 1.10.2

I am running autoconf 2.63:
$ autoconf --version
autoconf (GNU Autoconf) 2.63


When I put color-tests in my AM_INIT_AUTOMAKE in configure.ac and run
autoreconf, I get this:

configure.ac:9: option `color-tests' not recognized
autoreconf: automake failed with exit status: 1


When I put it instead in AUTOMAKE_OPTIONS in my Makefile.am, I get this:

Makefile.am:13: option `color-tests' not recognized
autoreconf: automake failed with exit status: 1



What am I doing wrong?

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

[NightStrike]

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 has it been stale?

Re: GNU Make Extensions

[NightStrike]

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 releases should be made with that turned off.  Is that not how it
>>> works?
>>
>> Maintainer mode is optional.  Regardless, when using wildcards the
>> maintainer (i.e. you) will become frustrated with the additional delay added
>> to 'make'.  It would be similar (or identical) to autotools regenerating the
>> project every type you execute 'make'.
>
> Not if automake flattens it when running automake.  The idea was that
> automake would translate the wildcard into the full file list.
>

Oh, nevermind.. You're saying that make will invoke automake to check
to see if Makefile.in needs to be updated. I understand, I think,
what you were saying.

Re: GNU Make Extensions

[NightStrike]

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
>> works?
>
> Maintainer mode is optional.  Regardless, when using wildcards the
> maintainer (i.e. you) will become frustrated with the additional delay added
> to 'make'.  It would be similar (or identical) to autotools regenerating the
> project every type you execute 'make'.

Not if automake flattens it when running automake.  The idea was that
automake would translate the wildcard into the full file list.

Re: GNU Make Extensions

[NightStrike]

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 for the user than
>>> for the software developer.
>>
>> Build behaviour wouldn't change, would it? Makefile.in would have the
>> same contents as before
>
> You might notice that stark lack of interest on the list with discussing
> this issue since it has been discussed to death several times before.
>
> Note that normally when one types 'make' the build environment checks to see
> if it is up to date, and if is not up to date, then various 'auto' tools are
> executed to bring it up to date before any actual building starts.   If the
> build depends on the list of files which happen to be available in a
> directory, then the current list of files needs to be checked and the
> makefiles regenerated (if necessary) before any actual building can ensue.
>  For large projects this could take substantial time.

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?

Re: GNU Make Extensions

[NightStrike]

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 a problem is FAR less than the
>> current problems of maintaining the source file list.  Doing it
>> manually has already proven so error-prone as to cause significant
>> lost time.
>
> The problem is not so much the crafting of wildcards as it is unintended
> "accidents" in the filesystem.  For my own project I do have some bits which
> are based on wildcards and several times files have been bundled up which I
> did not intend to be included.

Ok, so again, I should be allowed to accept that *potential* risk as
being far less than the current situation of *actual* risk which is
causing problems.  If I knew anything about Perl, I'd just do it
myself, but alas, the automake source confounds me :(

Re: GNU Make Extensions

[NightStrike]

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 against it that I've heard is
>> that it is a GNU-only option.  However, I've suggested in the past
>> that it'd be great if Automake can just process the wildcard and
>> output the Makefile.in accordingly.  It sounds like my suggestion
>> wasn't that wild afterall if Automake can do this currently for things
>> like +=.
>
> Automake is written in Perl, which is a very powerful scripting language.
>  Of course it could easily be extended to do such a thing.
>
>> When you have a library with 357 source files, the list in Makefile.am
>> becomes unwieldy.
>
> I think that the fear is that the package will accidentally end up with 356
> or 358 source files but that exactly 357 are required. There is the idea
> that software should be constructed by design rather than by accident.

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 a problem is FAR less than the
current problems of maintaining the source file list.  Doing it
manually has already proven so error-prone as to cause significant
lost time.

What I guess is missing here is that I am not advocating that certain
desirable extensions be *required*, just that they be *available*.

Re: GNU Make Extensions

[NightStrike]

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 over portable make syntax,
> i.e., automake will flatten the += and 'make' won't ever see it.
>
> Cheers,
> Ralf
>
>

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 against it that I've heard is
that it is a GNU-only option.  However, I've suggested in the past
that it'd be great if Automake can just process the wildcard and
output the Makefile.in accordingly.  It sounds like my suggestion
wasn't that wild afterall if Automake can do this currently for things
like +=.

When you have a library with 357 source files, the list in Makefile.am
becomes unwieldy.

Re: Multilib sources and variables

[NightStrike]

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 += 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 don't want to list them
>> twice (and subsequently maintain two lists and forget to keep updating
>> the two lists.)  The only difference is adding the -m32 flag (which
>> I'm hoping is correctly placed in CPPFLAGS, and not CFLAGS... I never
>> remember which flags go where).
>
> Typically, -m32 either goes right on to the compiler, or it goes in both
> CPPFLAGS and LDFLAGS.  Since you don't link here, that looks ok.

So if I put something in CPPFLAGS, gcc won't pass that on to the
linker for LDFLAGS?

Re: Multilib sources and variables

[NightStrike]

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.
>
> (In other words, you are missing -m64. And perhaps some logic
> so that lib64 is not built in pure 32-bit environments.)

That's ok.  I have that covered elsewhere in the makefile.  Also, this
is for the mingw-w64.sf.net project, which is a crt for Win64, so
there aren't too many instances where someone would not be using the
gcc toolchain that targets 64-bit.

Multilib sources and variables

[NightStrike]

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 don't want to list them
twice (and subsequently maintain two lists and forget to keep updating
the two lists.)  The only difference is adding the -m32 flag (which
I'm hoping is correctly placed in CPPFLAGS, and not CFLAGS... I never
remember which flags go where).

So is it ok to do the variable thing?

Re: per-directory options

[NightStrike]

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
>> 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
>
> No, I'm afraid.

I'm guessing that means it's not in anyone's queue, then, either.. :(

>> I know I ask about it a lot, and I remember seeing posts about it
>> awhile ago that looked promising regarding getting that feature.
>
> Hmm.  Were there patches?  I don't remember any.

I guess not.  What language is automake written in?  I could take a
stab at it, depending.  c++, as an example, is easier for me than
straight c.

> I assume using subdir Makefiles together with AM_CPPFLAGS is out of the
> question for you, right?

It's not entirely out of the question, but I probably wouldn't do it,
as the Makefile.am is already setup to handle a bunch of _CPPFLAGS
things.