On 12 Dec 2021 16:17, Karl Berry wrote:
> Does anyone here use or know of an active system where plain
> rm -f
> with no arguments fails? I mean, exits with bad status?
>
> We are considering changing Automake to assume this works,
> although we'd provide for a workaround just in case, something
currently the automake website only hosts one manual version -- the latest.
when working with older code bases, especially when trying to update them
to newer versions, it can be helpful to have the older manual available to
quickly refer to. can we do this for automake ? i'm thinking of just the
On 18 Jan 2022 19:27, Karl Berry wrote:
> Having multiple versions of the manual online sounds all to the good to
> me. As long as it's being done at all, I wouldn't hesitate to put up
> the manuals for every release, not just the major releases. For 1.16.x,
> I'm afraid I rather broke the previou
the ACLOCAL_PATH functionality is useful (adding search dirs after -I),
but a bit unwieldy as an env var. any reason we can't add a command line
option for this ? call it --aclocal-path ? or --extra-system-acdir ?
or some other other boring name ?
for context, when cross-compiling, autotools (i
On 19 Jan 2022 16:05, Karl Berry wrote:
> Hi Mike,
>
> the ACLOCAL_PATH functionality is useful (adding search dirs after -I),
> but a bit unwieldy as an env var. any reason we can't add a command line
> option for this ?
>
> Seems like a fine idea to me.
>
> call it --aclocal
as folks are aware, some projects require specific versions of autotools.
the exact reasons don't matter (e.g. committed files ala gcc/binutils/gdb,
working on an old branch/release, etc...). i'd like to focus on one part:
downstream distros will often carry backports to keep older versions workin
i can work with this
so plan is to update maintainer/maint.mk:
* web-manual will insert a link to the full versioned index in the index.html
that gendocs.sh produces
* i'm assuming that we don't want to modify lib/gendocs_template since it's
synced with upstream gnulib
* web-manual-update
On 26 Jan 2022 19:50, Karl Berry wrote:
> so the default manual/ landing page & manual will be unchanged from today
> other than having a link to the full versioned index
>
> What url/filename are you thinking for the "full versioned index"?
per your request, the default is unchanged. e.
On 27 Jan 2022 15:21, Karl Berry wrote:
> per your request, the default is unchanged.
>
> I understand (and thanks), but my question was about the "table"
> (whether it's actually a or not):
>
> * (Feb 2018) GNU Automake 1.16 (HTML PDF)
> * (Dec 2014) GNU Automake 1.15 (HTML PDF)
> * (Jun
On 28 Jan 2022 16:35, Karl Berry wrote:
> i was planning on the full index being maintained here:
> https://www.gnu.org/software/automake/manual/index-full.html
>
> Sounds good.
>
> >>See the [full version index] for other versions of the manual.
>
> Good. Maybe something lik
On 29 Jan 2022 15:56, Karl Berry wrote:
> https://www.gnu.org/software/automake/manual/index-full.html
>
> It looks nice, but the plethora of versions becomes rather an
> undifferentiated mass. Maybe make each major release its own
> , as in:
>
> Automake 1.16 releases:
>
> 1.16* versions
>
On 30 Jan 2022 15:15, Karl Berry wrote:
> > https://www.gnu.org/software/automake/manual/index-full.html
>
> It's better, but how about a non-blank line?
>
> (does obey table cells? I'm never sure.)
>
> Obviously we're getting down to trivialities, feel free to ignore :).
i actually te
context: https://bugs.gnu.org/53340
how portable is xargs ? like, beyond POSIX, as autoconf & automake both
support non-POSIX compliant systems. i want to use it in its simplest
form: `echo $var | xargs rm -f`.
automake jumps through some hoops to try and limit the length of generated
command l
On 14 Feb 2022 19:53, Paul Eggert wrote:
> On 2/14/22 19:45, Mike Frysinger wrote:
> > how portable is xargs ?
>
> It can be a porting problem, unfortunately. There are several corner
> cases that various implementations don't get right. I expect this is why
> the GN
On 15 Feb 2022 08:29, Bob Friesenhahn wrote:
> A problem with xargs is that without using the GNU -O or --null
> argument and null-terminated arguments, file names containing spaces
> won't be handled properly. File names containing spaces is an issue
> for Autotools in general. This is again
On 15 Feb 2022 20:25, Jacob Bachmeyer wrote:
> Dan Kegel wrote:
> > Meson is a candidate for such a next-gen config system. It is in python,
> > which does not quite qualify as usable during early uplift/bootstrap, but
> > there are C ports in progress, see e.g. https://sr.ht/~lattis/muon/
>
> *P
On 15 Feb 2022 21:17, Jacob Bachmeyer wrote:
> Mike Frysinger wrote:
> > context: https://bugs.gnu.org/53340
> >
> Looking at the highlighted line in the context:
thanks for getting into the weeds with me
> > > echo "$$py_files" | $(am__pep3147_tweak) |
On 17 Jul 2023 16:51, Karl Berry wrote:
> Hi Jan,
>
> Current automake likely won't have anything in store already,
>
> Not that I know of.
>
> a_SOURCES = $(addprefix aprog/,main.c foo.c bar.c baz.c)
>
> I've often wanted this myself. I'd certainly welcome a patch for it.
>
> Please w
On 01 Dec 2023 17:39, Nick Bowler wrote:
> On 2023-12-01 15:37, Jan Engelhardt wrote:
> > On Friday 2023-12-01 21:13, Mike Frysinger wrote:
> >> On 17 Jul 2023 16:51, Karl Berry wrote:
> >>> Hi Jan,
> >>>
> >>> Current automake likely won&
On 01 Dec 2023 21:37, Jan Engelhardt wrote:
> On Friday 2023-12-01 21:13, Mike Frysinger wrote:
> >On 17 Jul 2023 16:51, Karl Berry wrote:
> >> Hi Jan,
> >>
> >> Current automake likely won't have anything in store already,
> >>
> >>
On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
> Karl Berry wrote:
> > jb> a more thorough test would locate the autom4te script and grep it
> > for the perllibdir that was substituted when autoconf was
> > configured.
> >
> > I guess that would work.
>
> Challenge accepted. Here's a re
On 02 Dec 2023 19:17, Zack Weinberg wrote:
> On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
> > The best way to check if high-resolution
> > timestamps are available to autom4te is to have perl load
> > Autom4te::FileUtils and check if that also loaded Time::HiRes.
> >
> > The problem
On 02 Dec 2023 18:33, Jacob Bachmeyer wrote:
> Zack Weinberg wrote:
> > On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
> >> The best way to check if high-resolution
> >> timestamps are available to autom4te is to have perl load
> >> Autom4te::FileUtils and check if that also loaded Ti
On 02 Dec 2023 17:07, Jacob Bachmeyer wrote:
> Mike Frysinger wrote:
> > On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
> >> Karl Berry wrote:
> >>> jb> a more thorough test would locate the autom4te script and grep it
> >>> for the perl
On 28 May 2022 12:14, Jim Meyering wrote:
> A few days ago I was preparing to release grep and wanted to make sure
> it'd work with the latest automake and autoconf, so I built and installed
> each from master. That exposed these errors when bootstrapping grep. I
> think it was a prerequisite to ha
i think you might be describing this bug report:
https://debbugs.gnu.org/60508
-mike
signature.asc
Description: PGP signature
On 06 Apr 2023 02:34, Wu Zhenyu wrote:
> https://www.gnu.org/software/automake/manual/html_node/Python.html
> describe how to package python by automake. I have
>
> $ tree src/foobar
> src/foobar
> ├── __init__.py
> ├── __main__.py
> └── utils
>├── a.py
>
On Tuesday, December 07, 2010 13:56:35 Bruce Korb wrote:
> Thank you. automake list folks -- the main question is
> "Why are .m4 files being installed and how can I prevent it?"
because your top level Makefile.am is using:
aclocal_DATA = ...
when i think you should be using:
noinst_DATA = ...
(ob
i'm working on a project (urjtag) that has yacc/lex files in it. and other
files in the directory depend on the generated output from yacc/lex. so the
automake file looks something like:
libbsdl_la_SOURCES = \
vhdl_bison.y \
bsdl_bison.y \
bsdl.c \
bsdl_se
i can't imagine this is a big runtime penalty, so why does configure check for
the perl's thread settings and then hardcode that in the generated automake ?
it means if you change your perl config or deploy an automake package on a
system that has threads disabled, you get errors when trying to
On Friday 11 January 2013 04:08:26 Stefano Lattarini wrote:
> On 01/11/2013 05:07 AM, Mike Frysinger wrote:
> > i can't imagine this is a big runtime penalty, so why does configure
> > check for the perl's thread settings and then hardcode that in the
> > generated
On Friday 11 January 2013 12:21:24 Stefano Lattarini wrote:
> On 01/11/2013 06:11 PM, Mike Frysinger wrote:
> > On Friday 11 January 2013 04:08:26 Stefano Lattarini wrote:
> >> On 01/11/2013 05:07 AM, Mike Frysinger wrote:
> >>> i can't imagine this is a big run
the AM_CONDITIONAL documentation states it must always be executed. that's
fine. but what if i want to be lazy?
for example, i have code like so:
AC_DEFUN([_FOKER_DEFINE], [dnl
AC_DEFINE([FOKER_]$1[_]m4_toupper($3), [1], [Define is the ]$2[ is ]$3)
])
AC_DEFUN([_FOKER_ARCH], [_FOKER_DEFINE(
On Saturday 01 June 2013 19:27:46 Kip Warner wrote:
> On Fri, 2013-05-31 at 08:31 -0500, Robert Boehne wrote:
> > I don't quite understand why you think you need the rest linked
> > statically,
>
> Libraries like the following may not be present on the end user's system
> already:
be aware that w
On Sunday 02 June 2013 01:10:36 Kip Warner wrote:
> On Sat, 2013-06-01 at 23:14 -0400, Mike Frysinger wrote:
> > be aware that what ever version of glibc & gcc you use to build, the end
> > user cannot have a version older than that or it'll fail to start
>
> Do y
tes the comment handling in a few places under
the assumption that the behavior i'm seeing is a bug :)
-mike
2006-03-16 Mike Frysinger <[EMAIL PROTECTED]>
* aclocal.in (scan_configure_dep): Ignore ## lines.
(scan_file): Remove dnl and # comments.
* tests/commen11.test: New file.
* test
On Thursday 16 March 2006 23:24, Ralf Wildenhues wrote:
> Maybe even better if you test the other comment styles as well.
attached
-mike
2006-03-16 Mike Frysinger <[EMAIL PROTECTED]>
* aclocal.in (scan_configure_dep): Ignore ## lines.
(scan_file): Remove dnl and # comments.
* tests
On Thursday 16 March 2006 19:04, Mike Frysinger wrote:
> ive attached a patch which updates the comment handling in a few places
> under the assumption that the behavior i'm seeing is a bug :)
seems the deletion of '#.*' is too aggressive ... updated patch removes just
dnl comments now ...
-mike
On Thursday 16 March 2006 19:04, Mike Frysinger wrote:
> ive attached a patch which updates the comment handling in a few places
> under the assumption that the behavior i'm seeing is a bug :)
ok, previous patch was a little too aggressive ... it'd keep '#' comments from
On Thursday 02 November 2006 23:51, Praveen M R wrote:
> I am getting following message when I enter automake --add-misssing
> I feel I am doing wrong in Makefile.am.
we can only guess at what you're doing wrong unless you actually post the
Makefile.am
-mike
pgp73JtHwWvJP.pgp
Description: PGP s
40 matches
Mail list logo
