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

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

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

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

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: [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: 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: 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: 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: 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?

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

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

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

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
>

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

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: 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: [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: 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: 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: 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.

PING: Automake list

[NightStrike]

I see no messages in the archives for this list for the past two
years.  Is this list dead?  If so, where is the appropriate place for
receiving automake support?

Re: PING: Automake list

[NightStrike]

On 8/9/07, Noah Slater <[EMAIL PROTECTED]> wrote:
> > I see no messages in the archives for this list for the past two
> > years.  Is this list dead?  If so, where is the appropriate place for
> > receiving automake support?
>
> This is a very low volume list - but not /that/ low volume.
>
> You must looking in the wrong place.

I'm looking here:
http://sources.redhat.com/ml/automake/

It's linked to from here:
http://sources.redhat.com/automake/#lists

Where should I look instead for automake archives?  That seems like
the "official" place.  Is the archiver broken?

(mail resent because I forgot to do a "reply all".  Sorry.)

Overriding all commands in Makefile.am

[NightStrike]

Since this list is obviously not dead, here's my first of several questions:

(this is all with automake 1.10)

How do I individually override everything that takes place for a given
target?  For example, if I have this:

lib_LIBRARIES = libmylib.a
libmylib_a_SOURCES = source1.c source2.c

The resulting Makefile will perform:

$(CC) $(AM_CPPFLAGS) -o source1.o source1.c
$(CC) $(AM_CPPFLAGS) -o source2.o source2.c
$(AR) (AR_FLAGS) libmylib.a source1.o source2.o
$(RANLIB) libmylib.a

I have the ability to override the AR command by setting libmylib_a_AR
to any arbitrary set of commands, allowing me to have incredible
control over step 3 above.  However, I have not found out how to do
the same for steps 1, 2, and 4 (or at the very least prevent RANLIB
from running).  For instance, I could, if I chose, do this:

lib_LIBRARIES = libmylib.a
libmylib_a_SOURCES = source1.c source2.c
libmylib_a_AR = echo \!* > /dev/null

and it would serve as a very kludgey (albeit effective) way to disable
the AR command for that target only (this is just an example..
obviously there are other, better ways to do it).  How do I achieve
the same overriding capabilities for everything?

Re: PING: Automake list

[NightStrike]

On 8/9/07, Noah Slater <[EMAIL PROTECTED]> wrote:
> > I'm looking here:
> > http://sources.redhat.com/ml/automake/
>
> You're guess is a good as mine, sorry.

I'm assuming that means that it's blank for you, too, then.  Has
nobody been checking the archives since 2005?

Re: Overriding all commands in Makefile.am

[NightStrike]

On 8/9/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Thu, Aug 09, 2007 at 04:49:00PM CEST:
> >
> > How do I individually override everything that takes place for a given
> > target?
>
> I don't think there is a general way to do that.  You can use 'make -n'
> if you wish to not execute commands, or override the RANLIB or AR or CC
> (or COMPILE) macros.

I guess what I meant is, we have, using the example in the automake
manual, maude_LINK and maude_AR.  Why not maude_CC, maude_RANLIB, etc?

> > For instance, I could, if I chose, do this:
> >
> > lib_LIBRARIES = libmylib.a
> > libmylib_a_SOURCES = source1.c source2.c
> > libmylib_a_AR = echo \!* > /dev/null
>
> Serious question: why do you want or need to do this?  Automake
> generally allows flexibility where it's necessary for portability
> but if you don't have ar, then libmylib.a can't be built; however
> AC_PROG_RANLIB will set @RANLIB@ to ':' for you if not present --
> not all systems have/need a ranlib.

Well, I don't want or need to do this exactly.  I was just
illustrating that I *could*.  I'll give a better example of something
that I'm doing with automake that I know is wrong but that I can't
figure out how to do properly.

For a particular project, there are a handful of .c files that need to
be compiled to .o files and installed as .o files, not linked into any
executable.  I came up with this ugly workaround:

noinst_PROGRAMS = dummy
dummy_SOURCES = \
  CRT_fp8.c CRT_fp10.c txtmode.c binmode.c crtbegin.c crtend.c
dummy_LINK = \
  @echo \!* > /dev/null

This causes make to try to relink all the .o files into dummy.exe
every time, but it's only an echo command, so the overhead is minimal.
 I'm left with the desired .o files that aren't linked together, but I
still have all of the dependency tracking that automake provides.  Now
to compound the issue, these files all need special CC commands:

crtexe.c crtdll.c

Specifically, the first gets compiled into both crt1.o and crt2.o, and
the second gets compiled into both dllcrt1.o and dllcrt2.o.  The
compilation options for XX1.o are the same, and the options for XX2.o
are the same.  I came up with this equally ugly workaround:

BUILT_SOURCES = crt1.o crt2.o dllcrt1.o dllcrt2.o
crt1.o:
$(CC) $(AM_CPPFLAGS) -I$(top_srcdir) -D__CRTDLL__ -U__MSVCRT__ -c
$(top_srcdir)/crtexe.c -o $@
crt2.o:
$(CC) $(AM_CPPFLAGS) -I$(top_srcdir) -D__MSVCRT__ -U__CRTDLL__ -c
$(top_srcdir)/crtexe.c -o $@
dllcrt1.o:
$(CC) $(AM_CPPFLAGS) -I$(top_srcdir) -D__CRTDLL__ -U__MSVCRT__ -c
$(top_srcdir)/crtdll.c -o $@
dllcrt2.o:
$(CC) $(AM_CPPFLAGS) -I$(top_srcdir) -D__MSVCRT__ -U__CRTDLL__ -c
$(top_srcdir)/crtdll.c -o $@


So you see, I'm trying to find a better way to handle the uniqueness
of this project.  Now, keep in mind, I have never used automake
before, and my first attempt at it was to reverse engineer an existing
set of Makefiles into Makefile.am to generate the original Makefiles
(silly, I know).  I've been using the automake manual as a bible, and
have taken away much more from it that's even there, but obviously I'm
still missing some fundamentals here.  What I'm doing up above can
most likely be done in a better way -- I just don't know how.

Re: directory prefix on .o

[NightStrike]

On 8/9/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> Hi again :)
>
>
> in a different project, I have a number of files that have the same
> filename, but live in different directories, for example
>
> project/module1/hooks.c
> project/module1/m1.c
> project/module2/hooks.c
> project/module2/m2.c
> etc.
> project/Makefile.am
>
> I'd really like to avoid using make recursion (and all the reasons are
> described in the automake info page nicely). The flat Makefile.am I have
> come up so far is
>
> lib_LTLIBRARIES = module1.la module2.la
> module1_la_SOURCES = module1/hooks.c module1/m1.c
> module2_la_SOURCES = module2/hooks.c module2/m2.c
> etc.
>
> Unfortunately, it does not seem like the directory is encoded into the
> object file, hence automake will fail on me since it wants to use
> hooks.o for both hooks.c files.
>
> Is it currently possible to make the directory part of the object name,
> e.g.  module1__hooks.o and module2__hooks.o for example? If not, I'm
> going to cook up a patch (*), but I'd wanted to go sure such a feature is
> not already available.

Maybe this is what you need, from the automake manual:

subdir-objects
If this option is specified, then objects are placed into the
subdirectory of the build directory corresponding to the subdirectory
of the source file. For instance if the source file is
subdir/file.cxx, then the output file would be subdir/file.o.

Re: Overriding all commands in Makefile.am

[NightStrike]

On 8/10/07, Bernd Jendrissek <[EMAIL PROTECTED]> wrote:
> On 8/10/07, NightStrike <[EMAIL PROTECTED]> wrote:
> > For a particular project, there are a handful of .c files that need to
> > be compiled to .o files and installed as .o files, not linked into any
> > executable.  I came up with this ugly workaround:
>
> How about something like:
>
> startupdir = $(libdir)/nightstrike
>
> # Abusing the notion of "scripts" here...
> startup_SCRIPTS = crt1.o crt2.o crtspecialflags.o
>
> crtspecialflags_o_CFLAGS = $(AM_CFLAGS) $(CFLAGS) -fspecial-flag
>
> Then you let make figure out how to build the objects from C sources
> via the implicit .c.o: rule.

Overloading _SCRIPTS is similar to what I did with overloading
BUILT_SOURCES. I'm still left with the issue that crt1.o and crt2.o
are not built from crt1.c and crt2.c.

Perhaps I could use BUILT_SOURCES for its real intent and actually
create crt1.c and crt2.c from crtexe.c by simply doing:

crt%.c:
cp crtexe.c $@

But even there, I'm left with the original issue that I then need to
compile crt1 and 2.c into crt1.o and crt2.o.

Re: Overriding all commands in Makefile.am

[NightStrike]

On 8/10/07, NightStrike <[EMAIL PROTECTED]> wrote:
> On 8/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >  -- Original message --
> > From: NightStrike <[EMAIL PROTECTED]>
> > > Since this list is obviously not dead, here's my first of several 
> > > questions:
> > >
> > > (this is all with automake 1.10)
> > >
> > > How do I individually override everything that takes place for a given
> > > target?  For example, if I have this:
> > >
> > > lib_LIBRARIES = libmylib.a
> > > libmylib_a_SOURCES = source1.c source2.c
> > >
> > > The resulting Makefile will perform:
> > >
> > > $(CC) $(AM_CPPFLAGS) -o source1.o source1.c
> > > $(CC) $(AM_CPPFLAGS) -o source2.o source2.c
> > > $(AR) (AR_FLAGS) libmylib.a source1.o source2.o
> > > $(RANLIB) libmylib.a
> > >
> > > I have the ability to override the AR command by setting libmylib_a_AR
> > > to any arbitrary set of commands, allowing me to have incredible
> > > control over step 3 above.  However, I have not found out how to do
> > > the same for steps 1, 2, and 4 (or at the very least prevent RANLIB
> > > from running).  For instance, I could, if I chose, do this:
> > >
> > > lib_LIBRARIES = libmylib.a
> > > libmylib_a_SOURCES = source1.c source2.c
> > > libmylib_a_AR = echo \!* > /dev/null
> > >
> > > and it would serve as a very kludgey (albeit effective) way to disable
> > > the AR command for that target only (this is just an example..
> > > obviously there are other, better ways to do it).  How do I achieve
> > > the same overriding capabilities for everything?
>
> > How about
> >
> > ./configure AR=:  [other arguments etc.]
> >
> > You also might be able to force this override in configure.ac, but that 
> > would
> > defeat all the nifty things that the autotools are good for.
> > Perhaps what you really want is "--disable-static" on the configure command 
> > line.
> > You can also make this the default to disable static libs with:
> >
> >   # Turn off static libraries, since they aren't useful in python 
> > modules and
> >   # make the build process take too long.
> >   AC_DISABLE_STATIC
> >   AC_PROG_LIBTOOL
> >
> > One of these should have the desired effect, depending on what you desire. 
> > ;)
>
> I can't pass it in to configure, since this project includes many many
> files, most of which are built normally.  There's just a few oddballs
> that I need to override.  This is again my fault for not being more
> explicit and oversimplifying my goals.
>
> For most of the project, automake handles things well.  I use
> xx_LIBRARIES, _SOURCES, etc and AR and RANLIB do what they need to do
> very well.
>
> For a few libraries, however, things get screwy.  Here's one example
> of what I did to try to overcome that which I didn't understand:
>
> lib_LIBRARIES += libmoldname.a
> libmoldname_a_SOURCES = isascii.c iscsym.c iscsymf.c toascii.c
> strcasecmp.c strncasecmp.c wcscmpi.c
> libmoldname_a_AR = \
>   $(DLLTOOL) --as $(AS) -k -U --dllname msvcrt.dll --def
> $(top_srcdir)/moldname-msvcrt.def --output-lib $@ ; \
>   $(AR) $(ARFLAGS)
>
>
> Now, you can see that I am essentially trying to use DLLTOOL to work
> in a .def file before calling $(AR), and then $(RANLIB) follows
> naturally.  This works, but there is probably a more "correct" way of
> doing it.  Any ideas?

(Reposting due to wrapping errors)

lib_LIBRARIES += libmoldname.a

libmoldname_a_SOURCES = \
 isascii.c iscsym.c iscsymf.c toascii.c \
 strcasecmp.c strncasecmp.c wcscmpi.c \

libmoldname_a_AR = \
 $(DLLTOOL) --as $(AS) -k -U --dllname msvcrt.dll \
 --def $(top_srcdir)/moldname-msvcrt.def \
 --output-lib $@ ; \
 $(AR) $(ARFLAGS)

Re: Overriding all commands in Makefile.am

[NightStrike]

On 8/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>  -- Original message --
> From: NightStrike <[EMAIL PROTECTED]>
> > Since this list is obviously not dead, here's my first of several questions:
> >
> > (this is all with automake 1.10)
> >
> > How do I individually override everything that takes place for a given
> > target?  For example, if I have this:
> >
> > lib_LIBRARIES = libmylib.a
> > libmylib_a_SOURCES = source1.c source2.c
> >
> > The resulting Makefile will perform:
> >
> > $(CC) $(AM_CPPFLAGS) -o source1.o source1.c
> > $(CC) $(AM_CPPFLAGS) -o source2.o source2.c
> > $(AR) (AR_FLAGS) libmylib.a source1.o source2.o
> > $(RANLIB) libmylib.a
> >
> > I have the ability to override the AR command by setting libmylib_a_AR
> > to any arbitrary set of commands, allowing me to have incredible
> > control over step 3 above.  However, I have not found out how to do
> > the same for steps 1, 2, and 4 (or at the very least prevent RANLIB
> > from running).  For instance, I could, if I chose, do this:
> >
> > lib_LIBRARIES = libmylib.a
> > libmylib_a_SOURCES = source1.c source2.c
> > libmylib_a_AR = echo \!* > /dev/null
> >
> > and it would serve as a very kludgey (albeit effective) way to disable
> > the AR command for that target only (this is just an example..
> > obviously there are other, better ways to do it).  How do I achieve
> > the same overriding capabilities for everything?

> How about
>
> ./configure AR=:  [other arguments etc.]
>
> You also might be able to force this override in configure.ac, but that would
> defeat all the nifty things that the autotools are good for.
> Perhaps what you really want is "--disable-static" on the configure command 
> line.
> You can also make this the default to disable static libs with:
>
>   # Turn off static libraries, since they aren't useful in python 
> modules and
>   # make the build process take too long.
>   AC_DISABLE_STATIC
>   AC_PROG_LIBTOOL
>
> One of these should have the desired effect, depending on what you desire. ;)

I can't pass it in to configure, since this project includes many many
files, most of which are built normally.  There's just a few oddballs
that I need to override.  This is again my fault for not being more
explicit and oversimplifying my goals.

For most of the project, automake handles things well.  I use
xx_LIBRARIES, _SOURCES, etc and AR and RANLIB do what they need to do
very well.

For a few libraries, however, things get screwy.  Here's one example
of what I did to try to overcome that which I didn't understand:

lib_LIBRARIES += libmoldname.a
libmoldname_a_SOURCES = isascii.c iscsym.c iscsymf.c toascii.c
strcasecmp.c strncasecmp.c wcscmpi.c
libmoldname_a_AR = \
  $(DLLTOOL) --as $(AS) -k -U --dllname msvcrt.dll --def
$(top_srcdir)/moldname-msvcrt.def --output-lib $@ ; \
  $(AR) $(ARFLAGS)


Now, you can see that I am essentially trying to use DLLTOOL to work
in a .def file before calling $(AR), and then $(RANLIB) follows
naturally.  This works, but there is probably a more "correct" way of
doing it.  Any ideas?

Re: Overriding all commands in Makefile.am

[NightStrike]

On 8/10/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Fri, Aug 10, 2007 at 12:00:21AM CEST:
> > On 8/9/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > * NightStrike wrote on Thu, Aug 09, 2007 at 04:49:00PM CEST:
> > > >
>
> > Well, I don't want or need to do this exactly.  I was just
> > illustrating that I *could*.  I'll give a better example of something
> > that I'm doing with automake that I know is wrong but that I can't
> > figure out how to do properly.
>
> Ahh, you're going in the right direction: show what you want to achieve,
> not how you think it would be best to do it.


> > For a particular project, there are a handful of .c files that need to
> > be compiled to .o files and installed as .o files, not linked into any
> > executable.  I came up with this ugly workaround:
>
> Well, I think the cheapest and least error-prone operation is the
> creation of a static library.  Unless you need it otherwise, set
>   RANLIB = :

I need RANLIB for many other things in the makefile.  This would be
great if I could override ranlib on a per-target basis like I can with
"maude_a_AR" and "maude_LINK".  Is there any reason why RANLIB doesn't
follow the model of AR and LD?

> in this Makefile.am, and
>   noinst_LIBRARIES = libfoo.a
>   libfoo_a_SOURCES = ...
>
> You could even hack like this (but I won't guarantee that it won't break
> with another Automake release):
>   AR = :
>   ARFLAGS = >

Again, same issue.  I need these tools to operate normally for a large
portion of the build process.  It's just a handful of things that are
obscure.

> > Specifically, the first gets compiled into both crt1.o and crt2.o, and
> > the second gets compiled into both dllcrt1.o and dllcrt2.o.  The
> > compilation options for XX1.o are the same, and the options for XX2.o
> > are the same.  I came up with this equally ugly workaround:
>
> I don't think this is all that ugly.  But I don't see why you should
> need BUILT_SOURCES, at least not from this snippet alone; you could just
> as well list those .o files as dependencies to all-local, or put them in
> some libexecdir_SCRIPTS or so.  And I think you can make use of COMPILE
> to your advantage, instead of using CC directly.

Wow, lots of stuff here.  Ok, first, thanks for thinking it's not that
ugly.  I thought it was simply because "BUILT_SOURCES" is mainly
geared for building sources.  Granted, it can be extended as per the
manual's claim of it being a misnomer to build anything that has to be
built first, but anything you build with BUILT_SOURCES won't have the
same consistency checking as anything else.  For instance, there's no
"mv ./deps/foo.Tpo ./deps/foo.Po" or anything like that.

Now, again, as I make that statement, please understand that I'm very
new to automake, and the only things I know about it I gleaned from
the manual and from experimentation.  I really don't have any
theory-based knowledge (ie, "Why is it done a certain way?")

As for your suggestion, I don't know what COMPILE is.  Reading manual

Ok, it would appear that $(COMPILE) is more in the automake domain,
while $(CC) is more in the make domain.  So really, I should have been
using $(COMPILE) to begin with if I want to keep as much as possible
in the automake domain.  I'll change that.

Now about the _SCRIPTS idea.  Someone else in this thread suggested
it, as well, so it would be foolish of me to not examine it much more
closely now that multiple people are thinking the same idea
independently.

Again reading the manual, I see these two statements:
"Automake does not assume that scripts are derived objects; such
objects must be deleted by hand (see Clean)."
That's an issue, but can be worked around

"Since automake appears in the AC_OUTPUT macro, a target for it is
automatically generated, and it is also automatically cleaned (despite
the fact it's a script)."
This implies that I should put crt1.o, etc in AC_OUTPUT to force
automake to handle more of the work?  I'm a little confused on that.


For clarity, these are the original Makefile rules that I'm trying to
convert to the automake domain so that automake dumps out a Makefile
that does essentially the same thing:

crt1.o:
$(CC) -c -D__CRTDLL__ -U__MSVCRT__ $(ALL_CFLAGS) $< -o $@
crt2.o:
$(CC) -c -D__MSVCRT__ -U__CRTDLL__ $(ALL_CFLAGS) $< -o $@

dllcrt1.o:
$(CC) -c -D__CRTDLL__ -U__MSVCRT__ $(ALL_CFLAGS) $< -o $@

dllcrt2.o:
$(CC) -c -D__MSVCRT__ -U__CRTDLL__ $(ALL_CFLAGS) $< -o $@

Using the _SCRIPTS primary, I would replace CC in the above with
COMPILE, replace ALL_CFLAGS with AM_CPPFLAGS, and list all four
objects in lib_SCRIPTS.  Is that correct?  Would I then also place
these four targets in AC_OUTPUT?  autoconf doesn't know how to build
them, does it?  Is this more "automake-ish" than the BUILT_SOURCES
thing that I came up with?


Honestly, I think what I really need is just a _OBJECTS primary.  Does
/ Will such a thing exist?

Re: Overriding all commands in Makefile.am

[NightStrike]

Updates..

On 8/11/07, NightStrike <[EMAIL PROTECTED]> wrote:
> On 8/10/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > * NightStrike wrote on Fri, Aug 10, 2007 at 12:00:21AM CEST:
> > > On 8/9/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > > * NightStrike wrote on Thu, Aug 09, 2007 at 04:49:00PM CEST:
> "Since automake appears in the AC_OUTPUT macro, a target for it is
> automatically generated, and it is also automatically cleaned (despite
> the fact it's a script)."
> This implies that I should put crt1.o, etc in AC_OUTPUT to force
> automake to handle more of the work?  I'm a little confused on that.

Update: It would appear that the automake manual needs to be updated,
as the described AC_OUTPUT usage is deprecated.  How do we get the
manual updated?

> Using the _SCRIPTS primary, I would replace CC in the above with
> COMPILE, replace ALL_CFLAGS with AM_CPPFLAGS, and list all four
> objects in lib_SCRIPTS.

Update: It looks like $(COMPILE) already includes $(AM_CPPFLAGS) and
other things, so its usage is redundant.  I like this $(COMPILE).

Re: Overriding all commands in Makefile.am

[NightStrike]

On 8/12/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Sat, Aug 11, 2007 at 04:50:21PM CEST:
> >
> > Update: It would appear that the automake manual needs to be updated,
> > as the described AC_OUTPUT usage is deprecated.  How do we get the
> > manual updated?
>
> Preferably, by sending a patch against CVS HEAD to automake-patches, or
> writing a bug report in the GNATS or to bug-automake.  But for this case
> I'd just say you're looking at an outdated version of the manual.

http://www.gnu.org/software/automake/manual/html_mono/automake.html

"AC_OUTPUT([Makefile doc/Makefile intl/Makefile po/Makefile.in \
src/Makefile tests/Makefile tests/hello],
[chmod +x tests/hello])"

...

"Since automake appears in the AC_OUTPUT macro, a target for it is
automatically generated, and it is also automatically cleaned (despite
the fact it's a script)."

=

Those are two places in the above referenced document where it could
do with an update.

Re: declaring sources ...

[NightStrike]

On 8/15/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > Note all the ".cpp" files and the AM_CXXFLAGS and AM_LDFLAGS.  The cpp
> > files vary over time and I have to refresh the list every time.  Is there
> > anyway to declare something like *.cpp??
>
> No.  The limitation is intentional, because then you can have a
> ApplicationOld.cpp in your source tree, without having it automatically
> compiled or distributed.  Even with revision control, this is handy at
> times.

Why is this not a toggleable option of some sort?  Why force a user
into a difficult situation that will end up having a kludgey
workaround? (like something that auto-generates the makfile.am,
bringing the total layers to what.. 4?  some script > makefile.am >
makefile.in > makefile.  )  The justification sounds a little like
giving someone a gun but not ever letting him disengage the safety.

I understand why using $(wildcard ...) variables is discouraged, as
it's not portable.  Having automake generate the source file list
according to some regular expression is, however, an *extremely*
useful advanced tool.

Re: Overriding all commands in Makefile.am

[NightStrike]

On 8/15/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Mon, Aug 13, 2007 at 12:07:17AM CEST:
> > On 8/12/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > * NightStrike wrote on Sat, Aug 11, 2007 at 04:50:21PM CEST:
> > > >
> > > > Update: It would appear that the automake manual needs to be updated,
> > > > as the described AC_OUTPUT usage is deprecated.  How do we get the
> > > > manual updated?
> > >
> > > Preferably, by sending a patch against CVS HEAD to automake-patches, or
> > > writing a bug report in the GNATS or to bug-automake.  But for this case
> > > I'd just say you're looking at an outdated version of the manual.
> >
> > http://www.gnu.org/software/automake/manual/html_mono/automake.html
>
> The current manual can be found at
> <http://sources.redhat.com/automake/automake.html>.
>
> Let me see whether I get to updating the gnu.org one eventually...

Wow.. lots of differences here.  How come the various manual locations
are not updated and mirrored automatically?

Re: declaring sources ...

[NightStrike]

On 8/16/07, Jason Curl <[EMAIL PROTECTED]> wrote:
> NightStrike wrote:

> > Why is this not a toggleable option of some sort?  Why force a user
> > into a difficult situation that will end up having a kludgey
> > workaround? (like something that auto-generates the makfile.am,
> > bringing the total layers to what.. 4?  some script > makefile.am >
> > makefile.in > makefile.  )  The justification sounds a little like
> > giving someone a gun but not ever letting him disengage the safety.
> >
> > I understand why using $(wildcard ...) variables is discouraged, as
> > it's not portable.  Having automake generate the source file list
> > according to some regular expression is, however, an *extremely*
> > useful advanced tool.
> >
> I don't think it makes sense to have this feature. I have a bunch of
> source files that are conditionally compiled based on the system it's
> building on. Why would I want to compile these on all systems? I don't
> think it warrants (IMO) to increase the complexity of autoconf by adding
> another feature like this one. Instead of saying what I want in a build
> system, I'd have to change it to what I /don't/ want.
>
> For auditing purposes, I'd rather know precisely what's a part of my build.

An option that can be toggled, or an alternative approach to
specifying source files, is just that -- an alternative, an option.
No one would be forcing the use of wildcards.  It doesn't work for
your project -- great.  But there do exist projects for which it would
have benefits.  That's the purpose of offering options to people.

Re: Migration to Git?

[NightStrike]

On 9/30/07, Benoit SIGOURE <[EMAIL PROTECTED]> wrote:
> Hello,
> several GNU projects (including autoconf) have moved to Git, is there

Just curious... why git over svn?

Changing $libdir

[NightStrike]

If I do:

lib_LIBRARIES = libfoo.a
libfoo_a_SOURCES = foo.c

in the Makefile.am, libfoo.a will be installed into $(prefix)/lib.  If
I am using AC_CANONICAL_SYSTEM in configure.ac, I want to be able to
set build, host, and target for building a cross compiler.  I would
then want the above library to be installed into
$(prefix)/$(host)/lib.  How do I accomplish that?

$(COMPILE)

[NightStrike]

Where is $(COMPILE) documented?  When should it be used?  What does it
actually get set to?

Re: $(COMPILE)

[NightStrike]

On 10/16/07, Benoit SIGOURE <[EMAIL PROTECTED]> wrote:
> On Oct 16, 2007, at 10:05 AM, NightStrike wrote:
>
> > Where is $(COMPILE) documented?
>
> http://www.gnu.org/software/automake/manual/html_node/Program-
> variables.html#index-COMPILE-494
>
> > When should it be used?
>
> When you want to "compile a C source file" (quoting the manual).
> Maybe this works for C++ too (I haven't checked but I wouldn't be
> surprised).
>
> > What does it actually get set to?
>
> To whatever command that can actually "compile a C source file"  :)


Ah, thank you.  I couldn't find any of that information in the manual
because I kept searching for the text strings $(COMPILE) and
${COMPILE}.  D'oh!  Thanks for the quick response.

Re: $(COMPILE)

[NightStrike]

On 10/16/07, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Oct 2007, NightStrike wrote:
>
> > Where is $(COMPILE) documented?  When should it be used?  What does it
> > actually get set to?
>
> Read a generated Makefile and all secrets will be revealed.  Normally
> you should not care about $(COMPILE) since Automake takes care of it.

When writing my own rules, I want to make use of things like
$(COMPILE) and $(LINK) to keep my custom rules as much in the
"automake" domain as I can.

Re: $(COMPILE)

[NightStrike]

On 10/16/07, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Oct 2007, NightStrike wrote:
>
> > Where is $(COMPILE) documented?  When should it be used?  What does it
> > actually get set to?
>
> Read a generated Makefile and all secrets will be revealed.

Looks like here's my answer:

COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)

xxx_LIBRARIES does ranlib on install

[NightStrike]

If I place something inside the primary "_LIBRARIES", for instance
libmine.a, when I do a make install after doing a make, make runs
ranlib on that library.  Why is ranlib run during make install instead
of during make all?

Makefile.am assistance

[NightStrike]

I am trying to build a Makefile.am file "correctly".  This is what I
have so far:

http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/buildsystem/Makefile.am?revision=137&view=markup

Some issues that I've noted include installing all libraries as
executables instead of 644 (due to using _SCRIPTS for more than its
intended purpose) and the install target runs ranlib again for some
reason.  Does anyone have any suggestions on how to make this a
"better" Makefile.am?

Re: xxx_LIBRARIES does ranlib on install

[NightStrike]

On 10/16/07, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Oct 2007, NightStrike wrote:
>
> Regarding your question about executable DLLs, if you take a look in
> your Windows System directory you will see that DLLs are marked as
> executable.  Traditionally DLLs are found using the executable search
> path.
>

Ok, so I can leave it for the .dll files.  What about .a files?

Re: xxx_LIBRARIES does ranlib on install

[NightStrike]

On 10/16/07, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 16 Oct 2007, NightStrike wrote:
>
> > If I place something inside the primary "_LIBRARIES", for instance
> > libmine.a, when I do a make install after doing a make, make runs
> > ranlib on that library.  Why is ranlib run during make install instead
> > of during make all?
>
> Many systems supporting ranlib insist that ranlib be run on the
> library in its final location.  Otherwise the library is ignored.  I
> don't know if that is the case for MinGW.

Is it bad to run ranlib multiple times?  Once during make and again
during make install?

Re: Makefile.am assistance

[NightStrike]

On 10/19/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> | # These targets require special handling that automake can't
> | # yet support (or that I don't know how to do properly)
> | crtdir=$(prefix)/$(target)/lib
> | crt_SCRIPTS = \
> |   crt1.o crt2.
>
> There is nothing inherently wrong with defining ones own directories.
> You can even use crt_DATA here, to have mode 644.  Note that shared
> libraries should in general be executable though.

Should static libraries be executable?

Re: Makefile.am assistance

[NightStrike]

On 10/19/07, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> NightStrike <[EMAIL PROTECTED]> writes:
>
> > Ok.  I just tested your idea, and I am going to move all .a custom
> > targets to a _DATA primary, and leave the _SCRIPTS primary for just
> > the custom executable targets (like crt1.o, etc).
>
> crt1.o is DATA as well.

Yes, you are right.  Apparently, I should be using DATA for
everything, and so I am now.  I updated the svn repository with the
latest version.  I am again very open to any comments that people have
on how best to do things correctly.

Re: Makefile.am assistance

[NightStrike]

On 10/19/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Fri, Oct 19, 2007 at 09:14:22PM CEST:
> >
> > Should static libraries be executable?
>
> They need not be.  But it's no problem if they are.

Ok.  I just tested your idea, and I am going to move all .a custom
targets to a _DATA primary, and leave the _SCRIPTS primary for just
the custom executable targets (like crt1.o, etc).

That's at least a little better.  Thanks for the help thus far.

Re: Makefile.am assistance

[NightStrike]

On 10/19/07, Harlan Stenn <[EMAIL PROTECTED]> wrote:
> Why worry about which library files should be executable and which ones
> are not?
>
> Would it be easier to use:
>
>  foodir=/where/ever
>  foo_LIBRARIES = ...
>
> and let the generated Makefile handle getting the permissions right?

For 8 or so of the many many libraries, I do just that.  However, I
don't know how to use automake to build a makefile that generates the
bulk of the libraries the way that I need.  Observe:

crt_SCRIPTS = libcrtdll.a libmsvcrt.a libmsvcr80.a
libcrtdll.a libmsvcrt.a libmsvcr80.a:
base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
$(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
$(top_srcdir)/$${base}.def

To generate those three libraries, I do nothing other than run
dlltool, passing in the appropriate .def file.  There is no source
file to speak of, nor any ar or ranlib applied.  If I used the
_LIBRARIES primary, the way I understand it is that I would be
required to supply source files (I think), and I could not execute
just dlltool but instead ar and ranlib.

Do you know how to achieve the above effect with using the _LIBRARIES
primary instead of overriding the use of _SCRIPTS?

Re: Makefile.am assistance

[NightStrike]

ping..

On 10/16/07, NightStrike <[EMAIL PROTECTED]> wrote:
> I am trying to build a Makefile.am file "correctly".  This is what I
> have so far:
>
> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/buildsystem/Makefile.am?revision=137&view=markup
>
> Some issues that I've noted include installing all libraries as
> executables instead of 644 (due to using _SCRIPTS for more than its
> intended purpose) and the install target runs ranlib again for some
> reason.  Does anyone have any suggestions on how to make this a
> "better" Makefile.am?
>

-pipe passed to gcc via Automake

[NightStrike]

If I wanted -pipe passed in to gcc all the time, do I put that in
AM_CPPFLAGS or AM_CFLAGS?

Re: Makefile.am assistance

[NightStrike]

On 10/21/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Fri, Oct 19, 2007 at 09:25:08PM CEST:
> >
> > crt_SCRIPTS = libcrtdll.a libmsvcrt.a libmsvcr80.a
> > libcrtdll.a libmsvcrt.a libmsvcr80.a:
> > base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
> > $(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
> > $(top_srcdir)/$${base}.def
> >
> > To generate those three libraries, I do nothing other than run
> > dlltool, passing in the appropriate .def file.
>
> Let's deal with one library only.  For the moment, leave Automake out of
> the picture, this is a mere issue of how to write 'make' rules.

> Am I right in that the input files to dlltool in this case are
> foo.dll and foo.def, and the output is the import library libfoo.a?

Sort of.  foo.dll is not an actual file.

> Then write
>   libfoo.a: foo.dll foo.def
> rule...
>
> for each library.  If you can require GNU make (which I guess you can),
> then you can write one pattern rule
>   lib%.a: %.dll %.def
> rule...

I sort of did that for the very very long list of .a libs appended to
crt_DATA.  I wrote this further down in the makefile:

lib%.a:
$(DLLTOOL) $(DLLOPTS) --def $(top_srcdir)/lib/$*.def

But I didn't know how to adapt that for the extra command to dlltool,
which is '--dllname=foo.dll'

So what I did was the following (committed it as revision 151, too, so
you can see it in the svn repository) :
Index: Makefile.am
===
--- Makefile.am (revision 151)
+++ Makefile.am (working copy)
@@ -36,9 +36,13 @@ dllcrt1.o:
 dllcrt2.o:
$(COMPILE) -c $(top_srcdir)/crtdll.c -o $@ -D__MSVCRT__ -U__CRTDLL__

-libcrtdll.a libmsvcrt.a libmsvcr80.a:
-   base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
-   $(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
$(top_srcdir)/$${base}.def
+#libcrtdll.a libmsvcrt.a libmsvcr80.a:
+#  base=`echo $@ | sed -e 's/\.a//' -e 's/^lib//'`; \
+#  $(DLLTOOL) $(DLLOPTS) --dllname $${base}.dll --def
$(top_srcdir)/$${base}.def
+
+lib%.a: %.def
+   $(DLLTOOL) $(DLLOPTS) --dllname $*.dll --def=$(top_srcdir)/$*.def
+
 #libcrtdll.a:
 #  $(DLLTOOL) --as=$(AS) -k --dllname crtdll.dll --output-lib $@
--def $(top_srcdir)/crtdll.def
 #libmsvcrt.a:


Now, however, I have two rules called lib%.a that do different things.
 Somehow, make is getting it right, but I have no idea why.

> > Do you know how to achieve the above effect with using the _LIBRARIES
> > primary instead of overriding the use of _SCRIPTS?
>
> Well, I could tell you that Libtool can create DLLs plus import
> libraries (it names them libfoo.dll.a), but I don't think you want
> to hear that at this point.  ;-)

I'd love to hear about it.  If libtool can do this better, then I'll
use it.  I must confess, though, that I couldn't figure it out.  It
seemed to require foo.la as output libs instead of foo.a.

Re: Makefile.am assistance

[NightStrike]

On 10/21/07, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Ralf Wildenhues wrote:
>
> > Well, I could tell you that Libtool can create DLLs plus import
> > libraries (it names them libfoo.dll.a), but I don't think you want
> > to hear that at this point.  ;-)
>
> Libtool isn't appropriate here because he's not actually building any
> libraries, only synthesizing import libraries from a .def file for
> existing binary Microsoft .DLLs.

Is there no way to automate that task using built in primaries?  Or is
the way that I'm doing it the only way to do it?

Re: Custom Build

[NightStrike]

On 10/26/07, Eric Blake <[EMAIL PROTECTED]> wrote:
> This looks more like an automake question, so I've redirected the mail
> accordingly.  Perhaps the answer already lies in the automake manual, in
> creating your own suffix rules:
>
> http://sourceware.org/automake/automake.html#index-Adding-new-_0040code_007bSUFFIXES_007d-880
>

Does this work with libraries as well as programs?  Could I turn a
.def file into a .a file?  Currently, I do this:

lib%.a: %.def
$(DLLTOOL) $(DLLOPTS) --dllname $*.dll --def=$(top_srcdir)/$*.def

Then I put all the lib*.a files in a big foo_DATA variable.  What I
would rather do is make use of the _LIBRARIES primaries to do it that
way.  Is that possible, considering that I'm synthesizing import
libraries from a .def file instead of building them from source?

Re: NEWS: added support for lzma compression

[NightStrike]

On 10/11/07, Jim Meyering <[EMAIL PROTECTED]> wrote:
> FYI, I added support for LZMA[1] compression a few days ago:
>
>   http://lists.gnu.org/archive/html/automake-patches/2007-10/msg3.html
>
> So now you can put this in your configure.ac file
>   AM_INIT_AUTOMAKE([dist-lzma])
> and "make dist" will generate both .gz and .lzma compressed tarballs.
>
> This started when I discovered p7zip a few weeks ago and was flabbergasted
> to see that it compressed the coreutils tarball to a measly 3.3MB(!),
> while bzip2 managed to compress it to only 5.3MB.  The gzip'd tarball
> weighs in at 8.4MB.
>
> In addition, it usually decompressed at least twice as fast as bzip2.
> My other test case was the emacs tarball.  It compressed it to 24MB,
> which was 6MB smaller than the bzip2-compressed size.
> Pretty impressive.
>
> lzma uses the same core compression technology (based on 7zip, originally
> written for windows), but it's been converted to c99, and its command-line
> interface is a lot more like gzip and bzip2.
>
> For now, there is neither a mailing list, nor a publicly accessible
> repository for lzma, but with a little luck we'll have both before
> too long.
>
> [1] http://tukaani.org/lzma/
>
>
>
When will this be in an automake release?

Re: DLLTOOL without LIBTOOL

[NightStrike]

On 11/2/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Fri, Nov 02, 2007 at 05:43:05PM CET:
> > On 11/2/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > AC_CHECK_TOOL(DLLTOOL, dlltool, false)
> >
> > How does that handle cross configurations?  For instance, if the tool
> > is x86_64-pc-mingw32-dlltool?
>
> $ info --index-search=AC_CHECK_TOOL Autoconf

 -- Macro: AC_CHECK_TOOL (VARIABLE, PROG-TO-CHECK-FOR,
  [VALUE-IF-NOT-FOUND], [PATH])
 Like `AC_CHECK_PROG', but first looks for PROG-TO-CHECK-FOR with a
 prefix of the host type as determined by `AC_CANONICAL_HOST',
 followed by a dash (*note Canonicalizing::).  For example, if the
 user runs `configure --host=i386-gnu', then this call:
  AC_CHECK_TOOL([RANLIB], [ranlib], [:])
 sets `RANLIB' to `i386-gnu-ranlib' if that program exists in
 `PATH', or otherwise to `ranlib' if that program exists in `PATH',
 or to `:' if neither program exists.

 In the future, when cross-compiling this macro will _only_ accept
 program names that are prefixed with the host type.  For more
 information, see *Note Specifying the system type: Specifying
 Names.


Perfect!  You've shown me two things -- how this macro works, and how
to use "info" without pulling my hair out.  Thanks again!

DLLTOOL without LIBTOOL

[NightStrike]

Currently, the macro AC_PROG_LIBTOOL will search for dlltool and
define $(DLLTOOL) appropriately.  If I only want dlltool itself and
not the rest of the libtool package, is there some sort of
AC_PROG_DLLTOOL macro available?  The issue is that I need ranlib, and
using both AC_PROG_RANLIB And AC_PROG_LIBTOOL drops a warning.  I was
hoping there'd be a better way.

Re: DLLTOOL without LIBTOOL

[NightStrike]

On 11/2/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello NightStrike, whoever you are,

Hi :)

> * NightStrike wrote on Fri, Nov 02, 2007 at 05:29:01PM CET:
> > Currently, the macro AC_PROG_LIBTOOL will search for dlltool and
> > define $(DLLTOOL) appropriately.  If I only want dlltool itself and
> > not the rest of the libtool package, is there some sort of
> > AC_PROG_DLLTOOL macro available?
>
> FWIW, all AC_PROG_LIBTOOL does with DLLTOOL is
> AC_CHECK_TOOL(DLLTOOL, dlltool, false)
>
> so you can just do that yourself.

How does that handle cross configurations?  For instance, if the tool
is x86_64-pc-mingw32-dlltool?

> > The issue is that I need ranlib, and
> > using both AC_PROG_RANLIB And AC_PROG_LIBTOOL drops a warning.
>
> AC_PROG_LIBTOOL checks for ranlib and sets RANLIB as well.
> That's why you get the warning.

Er... oh.  So I removed AC_PROG_RANLIB, and proved that you are indeed
correct.  That pretty much takes care of everything :)

Thanks!

AC_PROG_LIBTOOL vs AM_PROG_LIBTOOL

[NightStrike]

Is there a difference between using AC_PROG_LIBTOOL and
AM_PROG_LIBTOOL?  I see both defined in the manual as synonymous, but
I may not be looking at the right place in the manual.

DLLTOOL flags

[NightStrike]

There are variables like AM_CFLAGS and AM_LDFLAGS.  Is there an
AM_DLLTOOLFLAGS variable that can be used to pass common parameters to
dlltool?

Conditional sources

[NightStrike]

I am trying to figure out how to do conditional sources.  Basically,
here is the setup:

lib/uuid.c
lib32/uuid.c

If I pass --with-m32 to configure, I want to use the second source.
If I don't, then I want to use the first.  I put this in configure.ac:

AC_ARG_WITH(m32,
[  --with-m32   Compile lib32 stuff.. testing only],
[  WITH_32=yes ],
[  WITH_32= ])
AM_CONDITIONAL(WITH32, test x$WITH_32 != x)

And I put this in Makefile.am:

if WITH32
  crtdir=$(prefix)/lib32
  uuidsrc = lib32/uuid.c
else
  crtdir=$(prefix)/$(target)/lib
  uuidsrc = lib/uuid.c
endif

crtlibs_LIBRARIES += libuuid.a
libuuid_a_SOURCES = $(uuidsrc)


When I run autoreconf, I get this:

Makefile.am: object `uuid.$(OBJEXT)' created by `lib32/uuid.c' and `lib/uuid.c'
make: *** [../crttest/Makefile.in] Error 1


Any ideas?

Re: AC_PROG_LIBTOOL vs AM_PROG_LIBTOOL

[NightStrike]

On 11/4/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Sun, Nov 04, 2007 at 07:26:51PM CET:
> > Is there a difference between using AC_PROG_LIBTOOL and
> > AM_PROG_LIBTOOL?  I see both defined in the manual as synonymous, but
> > I may not be looking at the right place in the manual.
>
> AM_PROG_LIBTOOL is an older name for AC_PROG_LIBTOOL.
> They are both aliases now.  LT_INIT will be another one.

I see.  I will use AC_PROG_LIBTOOL, then.  Thanks!

Re: DLLTOOL flags

[NightStrike]

On 11/4/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Sun, Nov 04, 2007 at 07:28:27PM CET:
> > There are variables like AM_CFLAGS and AM_LDFLAGS.  Is there an
> > AM_DLLTOOLFLAGS variable that can be used to pass common parameters to
> > dlltool?
>
> No, but also Automake provides no automatic rule generation in which
> DLLTOOL is ever used.  So if you write your own rule, nothing really
> prevents you from sticking $(AM_DLLTOOLFLAGS) in there somewhere.
> And of course you can also AC_SUBST([AM_DLLTOOLFLAGS]) from within
> configure.ac.
>
> Since this variable name matches the namespace reserved by Automake,
> a future release may happen to use dlltool and may happen to add some
> meaning to this variable.  Consider yourself warned! ;-)

I currently just set my own variable $(DLLOPTS).  I just wanted to
check to see if there's a better way.  And actually, of the 5794357983
messages I send to this list every day, most of them are me trying to
switch from my jury-rigged, makeshift ways of doing things to the real
way of using automake.  This list has been a great help in that
regard, so thanks again!

Re: Conditional sources

[NightStrike]

On 11/4/07, Benoit SIGOURE <[EMAIL PROTECTED]> wrote:
> On Nov 4, 2007, at 7:47 PM, NightStrike wrote:
>
> > I am trying to figure out how to do conditional sources.  Basically,
> > here is the setup:
> >
> > lib/uuid.c
> > lib32/uuid.c
> >
> > If I pass --with-m32 to configure, I want to use the second source.
> > If I don't, then I want to use the first.  I put this in configure.ac:
> >
> > AC_ARG_WITH(m32,
> > [  --with-m32   Compile lib32 stuff.. testing only],
> > [  WITH_32=yes ],
> > [  WITH_32= ])
>
> You might want to use AS_HELP_STRING here.
> http://www.gnu.org/software/autoconf/manual/html_node/Pretty-Help-
> Strings.html
>
> > AM_CONDITIONAL(WITH32, test x$WITH_32 != x)
> >
> > And I put this in Makefile.am:
> >
> > if WITH32
> >   crtdir=$(prefix)/lib32
> >   uuidsrc = lib32/uuid.c
> > else
> >   crtdir=$(prefix)/$(target)/lib
> >   uuidsrc = lib/uuid.c
> > endif
> >
> > crtlibs_LIBRARIES += libuuid.a
> > libuuid_a_SOURCES = $(uuidsrc)
> >
> >
> > When I run autoreconf, I get this:
> >
> > Makefile.am: object `uuid.$(OBJEXT)' created by `lib32/uuid.c' and
> > `lib/uuid.c'
> > make: *** [../crttest/Makefile.in] Error 1
>
> How about this (untested):
> crtlibs_LIBRARIES += libuuid.a
> libuuid_a_SOURCES =
>
> if WITH32
>crtdir=$(prefix)/lib32
>libuuid_a_SOURCES += lib32/uuid.c
> else
>crtdir=$(prefix)/$(target)/lib
>libuuid_a_SOURCES += lib/uuid.c
> endif
>
> ?

Same result.

Re: Conditional sources

[NightStrike]

On 11/4/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > On Nov 4, 2007, at 7:47 PM, NightStrike wrote:
> > > > AM_CONDITIONAL(WITH32, test x$WITH_32 != x)
> > > >
> > > > And I put this in Makefile.am:
> > > >
> > > > if WITH32
> > > >   crtdir=$(prefix)/lib32
> > > >   uuidsrc = lib32/uuid.c
> > > > else
> > > >   crtdir=$(prefix)/$(target)/lib
> > > >   uuidsrc = lib/uuid.c
> > > > endif
> > > >
> > > > crtlibs_LIBRARIES += libuuid.a
> > > > libuuid_a_SOURCES = $(uuidsrc)
> > > >
> > > >
> > > > When I run autoreconf, I get this:
> > > >
> > > > Makefile.am: object `uuid.$(OBJEXT)' created by `lib32/uuid.c' and
> > > > `lib/uuid.c'
> [...]
>
> You can adapt the hint from
>   info Automake 'Libtool Issues'
>
> to your example.  You'll have to live with a rewritten object file name
> in that case though.
>
>   info Automake 'Conditional Sources'
>
> has more useful information.

I was following those sections almost.  I missed that part about
having to add in a bogus _CFLAGS variable.  That seems somewhat
kludgey, doesn't it?  Automake should be able to detect the name
collisions in the conditional and rename the object files accordingly.
 Either that, or can't automake just put the object files in separate
directories, given my setup?  What I mean is, I have lib/uuid.c and
lib32/uuid.c.  If the object files were placed in the respective
directories, lib/uuid.o and lib32/uuid.o, then there would be no
collision and no need for a bogus _CFLAGS variable, yes?

Re: Conditional sources

[NightStrike]

On 11/4/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> Please learn about `subdir-objects', that helps.  It's indexed in the
> manual.

Ok, that has actually helped in multiple ways.  I am now using that
option, and it's good.  That gets me past one hurdle.  Now I am left
with the following:

First, if I do this:

crt64_SCRIPTS = libcrtdll.a
lib%.a: %.def
$(DLLTOOL) $(DLLOPTS) --dllname $*.dll --def=$(top_srcdir)/$*.def

Then libcrtdll.a and crtdll.dll are not put into their respective
subdirectories.  I'm guessing I have to manually change the output
file location in the build command.


The more important issue is that though I can now easily have multiple
sources with the same name, I cannot so easily have multiple libraries
with the same name.  Consider this:

lib32dir=$(prefix)/lib32
lib64dir=$(prefix)/lib64

lib32_LIBRARIES = libuuid.a
libuuid_a_SOURCES = lib32/uuid.c

lib64_LIBRARIES = libuuid.a
libuuid_a_SOURCES = lib64/uuid.c


The result is that a 'make all' builds libuuid.a once using the lib32
source.  The second _SOURCES variable isn't even set at all -- it's
actually ignored, and the lib64/uuid.c file is nowhere in the
resulting makefile.  When I do a 'make install', however, the 32-bit
version of the file libuuid.a is installed into both /lib32 and
/lib64.

So...  any more ideas?  Is there a way to build
the 32-bit libuuid.a file in one directory and the 64-bit version in
another?  I am now using the subdir-objects option, but AFAICS, that
only applies to the intermediate objects -- in this case, uuid.o.  Is
there a way to make that apply to the library itself?

Re: Conditional sources

[NightStrike]

On 11/5/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Mon, Nov 05, 2007 at 06:01:26AM CET:
> >
> > lib32dir=$(prefix)/lib32
> > lib64dir=$(prefix)/lib64
> >
> > lib32_LIBRARIES = libuuid.a
> > libuuid_a_SOURCES = lib32/uuid.c
> >
> > lib64_LIBRARIES = libuuid.a
> > libuuid_a_SOURCES = lib64/uuid.c
>
> Not sure why you don't write
>   lib32_LIBRARIES = lib32/libuuid.a
>   lib32_libuuid_a_SOURCES = lib32/uuid.c

I had tried it somewhere along the line, and it didn't work.  I'll try
it again with all the other latest fixes in.

On closer inspection, I see what you did.  You converted the slash to
an underscore.  Ok, see that's what I couldn't find -- I didn't know
that you could do that.  I was doing the first part -- specifying
"lib32_LIBRARIES = lib32/libuuid.a", but I messed up the variable for
_SOURCES...  Ok, I'm trying it now...

...

Egads!!  You're a genius!


> You may have to give up on your nice pattern rule, I'm not sure about
> that.  But specifying it explicitly a couple of times won't hurt.

That's step 2 :) :)

Re: AM_LIBS / AM_LDADD

[NightStrike]

On 11/6/07, Benoit SIGOURE <[EMAIL PROTECTED]> wrote:
> Hi list,
> would anyone be against the introduction of AM_LIBS / AM_LDADD
> (before the release of 1.11) to be more consistent with the existing
> AM_*flags?

Can you add to that also AM_DLLTOOLFLAGS?

Re: -pipe passed to gcc via Automake

[NightStrike]

On 10/21/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello whoever(?),
>
> * NightStrike wrote on Sun, Oct 21, 2007 at 07:13:19PM CEST:
> > If I wanted -pipe passed in to gcc all the time, do I put that in
> > AM_CPPFLAGS or AM_CFLAGS?
>
> You pass it to configure via CFLAGS, or CC:
>   ./configure CC='gcc -pipe'
>
> It makes not much sense in *CPPFLAGS: can't it help the assembly stage,
> too?  Neither does it make sense for you, the developer, to put it in
> AM_*, because the user may want to use a compiler different from gcc.
> If you know gcc will be used, then AM_CFLAGS should be fine.

As the project is a runtime for gcc, gcc is a required compiling tool
by default.  So in this case, I think AM_CFLAGS makes sense.

Multilib support

[NightStrike]

I just came across the multilib section of the automake manual:
http://www.gnu.org/software/automake/manual/automake.html#Multilibs

How can I find the status on this?  How "experimental" is "experimental"?

dir_PRIMARY_*FLAGS

[NightStrike]

Currently, it's possible to define flags for the general case and for
specific targets.  For instance, the following:

AM_CFLAGS = -flag1

foo_LIBRARIES = liba.a libb.a
liba_a_SOURCES = a.c
liba_a_CFLAGS = $(AM_CFLAGS) -flag2

libb_a_SOURCES = b.c
libb_b_CFLAGS = $(AM_CFLAGS) -flag3

However, is it possible to define flags common to a directory?  For
instance, say both liba and libb needed flag 2.  I'd have to write:

liba_a_CFLAGS = $(AM_CFLAGS) -flag2
libb_b_CFLAGS = $(AM_CFLAGS) -flag2 -flag3

Is it possible to specify something like foo_CFLAGS for all libraries
that get installed into that directory, but not affect the general
case?  Now yes, I can define my own variable called as such and
include it on the CFLAGS line of every library installed into foo.  I
am looking for a more automated way, however.

Re: AM_LIBS / AM_LDADD

[NightStrike]

On 11/6/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > Can you add to that also AM_DLLTOOLFLAGS?
>
> It's been mentioned before: Automake currently does not use dlltool.
> What would AM_DLLTOOLFLAGS be for then?  Support for it would be a null
> change.  Just put $(AM_DLLTOOLFLAGS) into your self-written rules that
> use dlltool, and there you have it: support for AM_DLLTOOLFLAGS!

The benefit of having it be part of Automake is that then I don't have
to specify it on each line.  The more stuff that is internal to
automake that I can use, the easier maintaining an automake file is.
For instance, I don't have to have a *_CFLAGS variable for every
target that is just equal to $(mycflags).  It's much easier to just
use the AM_CFLAGS variable provided, and it's a great feature of
Automake.  There is no such provision for dlltool, and doing it myself
is as cumbersome as doing *_CFLAGS manually.

Now, you state that Automake currently doesn't use dlltool.  I am
guessing you mean that dlltool support and usage is provided via
libtool, correct?  Should this request go to libtool, instead?  Would
the libtool project be able to add the global options variable?

Re: dir_PRIMARY_*FLAGS

[NightStrike]

On 11/6/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Tue, Nov 06, 2007 at 07:02:55PM CET:
> >
> > Is it possible to specify something like foo_CFLAGS for all libraries
> > that get installed into that directory, but not affect the general
> > case?  Now yes, I can define my own variable called as such and
> > include it on the CFLAGS line of every library installed into foo.  I
> > am looking for a more automated way, however.
>
> You could just use one Makefile per foodir, and then set AM_CFLAGS in
> each one.  Yeah, I guessed that you did not want to hear that.

Definitely not :)

The Automake manual makes reference to Peter Miller's paper
(http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html).  I've
been trying to adopt those ideas as much as possible, and so far have
succeeded in not requiring any recursive invocations of make.  Your
suggestion would require recursive make, correct?

Re: AM_LIBS / AM_LDADD

[NightStrike]

On 11/6/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * NightStrike wrote on Tue, Nov 06, 2007 at 07:09:21PM CET:
> > On 11/6/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > > > Can you add to that also AM_DLLTOOLFLAGS?
> > >
> > > It's been mentioned before: Automake currently does not use dlltool.
> [...]
> > The benefit of having it be part of Automake is that then I don't have
> > to specify it on each line.  The more stuff that is internal to
> > automake that I can use, the easier maintaining an automake file is.
>
> What you're really asking for here is support for some automatically
> generated rules that use dlltool, right?  How should such a rule look
> like, what should it do portably(!),

> and why would a portable project
> ever need such a rule when it could just use Libtool?

I guess I misunderstood the purpose of automake in general.  I
understand that automake itself is portable, but is automake intended
mainly for those projects which are themselves portable?

Regarding libtool, maybe I just don't understand how libtool works.  I
can't figure out how to use libtool to generate lib*.a.  It seems
intent on restricting outputs to only lib*.la.  I eventually gave up
and started manually invoking dlltool myself to build the lib*.a from
the *.def files.  Originally, I tried supplying the *.def files to the
lib_LIBRARIES primary, but I couldn't ever figure out how to get the
.def file recognized as a valid source file (even using SUFFIXES =
.def and .def.a: $(DLLTOOL) etc ).  So basically, what it comes down
to is that I think maybe my project is too limited to blend with
automake as simply as I initially envisioned, and my knowledge of
automake is too limited to make it do what I want without asking you
tons of questions (which you have been extremely kind in answering, I
might add... though it may not seem like it, I am learning a lot from
you, so thank you for that).

> If you have to write your own (unportable) rules anyway, then really
> there is nothing else that I see that could be done for you.
>
> Or do you just want
>   AM_DLLTOOLFLAGS = @AM_DLLTOOLFLAGS@
>
> put in every Makefile.in?  You can already have that, just use AC_SUBST
> in configure.ac.
>
> > Now, you state that Automake currently doesn't use dlltool.  I am
> > guessing you mean that dlltool support and usage is provided via
> > libtool, correct?  Should this request go to libtool, instead?  Would
> > the libtool project be able to add the global options variable?
>
> No.  While libtool happens to set ${DLLTOOL}, it doesn't really use it
> either.  I think it used to at some point in the past.
>
> I'm starting to be a bit puzzled.  I simply don't know what you want.

Your questions about my intentions have made my intents clearer to me.
 I now know what I want to do with DLLTOOL specifically.  Tell me what
you think of this idea:

I currently use $(COMPILE) to call gcc for manually written rules.
$(COMPILE) automatically includes $(C*FLAGS) as appropriate.  I keep
thinking that $(DLLTOOL) should do likewise, but $(DLLTOOL) is more
akin to $(CC) than $(COMPILE).  What I can do is:

AM_DLLTOOLFLAGS = -flag1
MAKEDLL = $(DLLTOOL) $(AM_DLLTOOLFLAGS)

Then I just need to use $(MAKEDLL) in the various locations it's necessary.

What do you think?

Another snag.. extension detection

[NightStrike]

I hit another snag in my project.  I am building a runtime as a
component of a cross compiler.  Configure has to determine the various
tools to use (denoted by passing --host=xx to configure), and I use
all of the AC_PROG_XX macros.  This may be an autoconf issue instead
of automake, but what happens is that configure tries to test for the
default extention of exe files.  The compiler doesn't make exe files,
however, because there is no runtime (chicken, egg).

Will automake be ok if I just do AC_CHECK_TOOL for gcc and g++ instead
of AC_PROG_CC and AC_PROG_CXX?

Re: Another snag.. extension detection

[NightStrike]

On Nov 18, 2007 10:11 AM, Benoit Sigoure <[EMAIL PROTECTED]> wrote:
>
> On Nov 18, 2007, at 9:02 AM, NightStrike wrote:
>
> > I hit another snag in my project.  I am building a runtime as a
> > component of a cross compiler.  Configure has to determine the various
> > tools to use (denoted by passing --host=xx to configure), and I use
> > all of the AC_PROG_XX macros.  This may be an autoconf issue instead
> > of automake, but what happens is that configure tries to test for the
> > default extention of exe files.  The compiler doesn't make exe files,
> > however, because there is no runtime (chicken, egg).
> >
> > Will automake be ok if I just do AC_CHECK_TOOL for gcc and g++ instead
> > of AC_PROG_CC and AC_PROG_CXX?
>
> Can't you populate the right cache variables to set the results you
> want without going through the tests?  It's a kludge, but it's less
> kludgy than what Ralf suggested, or so I think.

I'm not really sure what that means, nor how to do it.  Are you
suggesting distributing a configure cache?  Wouldn't that defeat the
purpose of using configure?

Re: Another snag.. extension detection

[NightStrike]

On 11/18/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This is an Autoconf issue, not an Automake one.

I thought as much.

> GCC has similar issues, too, and they use hacks like GCC_NO_EXECUTABLES
> to work around the issues, see
>  gcc/config/no-executables.m4
>
> in the GCC source tree, and other places where it's used.  Sorry.

I found GCC_NO_EXECUTABLES, which turned me to google, which turned me
on to AC_NO_EXECUTABLES.  I lined both up side by side, and it appears
that as of autoconf 2.61, AC_NO_EXECUTABLES appears to be pretty
complete and less messy (plus it's a native macro).  I'm not entirely
sure what the difference is, but I put the AC_ one in my Makefile.am
and it's now working very nicely once again.

As always, thanks muchly to this list for the tons of feedback and
assistance.  Hopefully you guys can make use of the mingw-w64 project
when this is all over.

Request for Review

[NightStrike]

I'm getting pretty finalized on the automake build system for my
project.  I was wondering, however, if anyone would mind going over
the configure.ac and Makefile.am files to proofread them and give any
suggestions, for instance if you see a better way to do things or if
it should be formatted differently.  I'm very open to all of your
suggestions, and would appreciate it.  Here's a link to the
latest versions:

http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-crt/

Also, I am doing a bunch of tests in configure.ac that I don't think
are necessary.  autoscan put them in there, and I commented a bunch
out.  For instance:

  60 #AC_HEADER_DIRENT
  61 #AC_HEADER_STDC
  62 #AC_CHECK_HEADERS([fcntl.h fenv.h float.h inttypes.h limits.h
locale.h malloc.h stddef.h stdint.h stdlib.h string.h sys/ioctl.h
sys/time.h sys/timeb.h termios.h unistd.h wchar.h wctype.h])

  65 AC_C_INLINE
  66 AC_TYPE_INT32_T
  67 AC_TYPE_PID_T
  68 AC_TYPE_SIZE_T
  69 AC_HEADER_TIME
  70 AC_TYPE_UINT32_T
  71 AC_C_VOLATILE
  72 AC_CHECK_TYPES([ptrdiff_t])

  75 AC_FUNC_MALLOC
  76 #AC_FUNC_MBRTOWC
  77 #AC_FUNC_REALLOC
  78 #AC_FUNC_STRTOD
  79 #AC_FUNC_VPRINTF
  80 #AC_CHECK_FUNCS([alarm atexit btowc fesetround floor ftruncate
gettimeofday isascii localeconv mbrlen memmove memset pow rint
setlocale sqrt strcasecmp strchr strncasecmp strtoull strtoumax])


I think that those macros are checking for the existance of those
functions on the build system, and since I am making a runtime for a
host system, they may not apply?  I think that those functions are
built by the mingw-w64 project, yes?  Does that make sense?  I think I
should remove them all, but I'm not sure.  I'd like an expert opinion
on the matter.

Re: how to install static library?

[NightStrike]

On 12/7/07, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Ting,
>
> * susan xie wrote on Wed, Dec 05, 2007 at 06:53:03PM CET:
> > >
> > > I have a third-party static library distributed with my software
> > > package, and I want to install it into the libraries during 'make
> > > install'. Do you know how to do that? Thanks in advance.
> But it seems very very ugly to me to do that.  Your package should just
> create the libraries.

If the library is third-party, then his package can't create it.