|
61075eab
|
2025-01-01T14:31:02
|
|
maint: make update-copyright
|
|
|
b80b5c47
|
2024-01-01T11:29:06
|
|
maint: make update-copyright
|
|
8cdbdda5
|
2023-11-21T08:30:00
|
|
automake: make the ARFLAGS default 'cr' instead of 'cru'.
In some GNU/Linux distributions people started to compile 'ar'
binary with --enable-deterministic-archives (binutils project).
That, however, in combination with our previous long time working
default AR_FLAGS=cru causes warnings on such installations:
ar: `u' modifier ignored since `D' is the default (see `U')
The 'u' option (at least with GNU binutils) did small optimization
during repeated builds because it instructed 'ar' to not
open/close unchanged *.o files and to rather read their contents
from old archive file. However, its removal should not cause a
big performance hit for usual workflows.
Distributions started using --enable-deterministic-archives
knowing that it would disable the 'u', just to rather have a bit
more deterministic builds.
Also, to justify this change a bit more, keeping 'u' in ARFLAGS
could only result in many per-project changes to override
Automake's ARFLAGS default, just to silence such warnings.
Fixes bug#20082. Reported by Eric Blake.
* bin/automake.in (handle_libraries): Use 'ARFLAGS=cr' by default.
* doc/automake.texi (Building a library): Mention the changed
ARFLAGS default.
(@c LocalWords): Replace 'cru' with 'cr'.
* m4/ar-lib.m4 (AM_PROG_AR): Cut out 'cru' string into separate
ARFLAGS variable with new default 'cr'.
* NEWS: Document.
|
|
34bdde96
|
2023-01-04T02:00:14
|
|
maint: make update-copyright
|
|
|
d096d4e6
|
2022-01-31T02:40:14
|
|
AM_PROG_AR: require before AC_PROG_AR
The new autoconf AC_PROG_AR macro has similar logic to what we have in
AM_PROG_AR, but less than what we need (since autoconf doesn't support
the MS archiver), so make sure we are run before AC_PROG_AR.
* m4/ar-lib.m4: Call AC_BEFORE for AC_PROG_AR.
|
|
6c8ff6a8
|
2022-01-12T14:15:12
|
|
maint: make update-copyright
|
|
|
a470a47f
|
2021-07-11T19:19:42
|
|
maint: make update-copyright
|
|
|
cf27a3df
|
2020-01-01T11:44:41
|
|
maint: make update-copyright
|
|
|
5ae02cc8
|
2019-10-14T13:46:55
|
|
maint: make update-copyright
|
|
bbaa4cdc
|
2018-01-04T16:19:30
|
|
maint: Update copyright years to 2018
This update has been made with 'make update-copyright'.
|
|
|
c2757b97
|
2017-09-19T13:43:07
|
|
maint: Reset master
|
|
|
d8add592
|
2017-03-02T18:55:53
|
|
maint: Update copyright years to 2017.
This update has been made with 'make update-copyright'.
|
|
|
1370ce5f
|
2017-01-01T08:34:49
|
|
maint: update copyright dates for 2017
* all files: Run this command, using update-copyright from gnulib:
UPDATE_COPYRIGHT_FORCE=1 \
UPDATE_COPYRIGHT_USE_INTERVALS=2 \
UPDATE_COPYRIGHT_MAX_LINE_LENGTH=79 \
update-copyright $(git ls-files)
|
|
5de75f07
|
2015-01-05T22:48:33
|
|
maint: update copyright years to 2015 (branch 'micro')
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
a78f63c5
|
2014-04-21T15:10:54
|
|
maint: update copyright years
We've been in 2014 already for few months now...
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
e90126cf
|
2013-05-15T10:14:46
|
|
AM_PROG_CC_C_O: don't rely on AC_PROG_CC_C_O, re-implement similar logic
** Theoretical problems of AC_PROG_CC_C_O:
Both cc and $CC are checked to see if they support the '-c' and '-o'
options together.
This behaviour is highly inconsistent with that of the other macros
related to C compiler checks -- which test only $CC.
It can also cause unwarranted uses of the 'compile' script on systems
where the default 'cc' is inferior, but the user is compiling with a
proper, different compiler (e.g., gcc).
** Practical problems with our previous implementation of C support m4
macros in Automake:
- AM_PROG_AR must now be called *before* AC_PROG_CC; this wasn't the
case before, and it turns out there are packages in the wild that
relied on the old behaviour.
- The cross-referenced requirements and macro rewrites juggled among
AC_PROG_CC, AC_PROG_CC_C_O and AM_PROG_CC_C_O caused warnings in
autoconf; for example, in our test 't/libobj3.sh', we could see
warnings like these (here slightly tweaked for legibility):
configure.ac:5: AC_REQUIRE: `AC_PROG_CC' expanded before required
autoconf/c.m4:567: AC_PROG_CC_C_O is expanded from...
autoconf/c.m4:429: AC_LANG_COMPILER(C) is expanded from...
autoconf/lang.m4:329: AC_LANG_COMPILER_REQUIRE is expanded from...
autoconf/general.m4:2606: AC_COMPILE_IFELSE is expanded from...
m4sugar/m4sh.m4:639: AS_IF is expanded from...
autoconf/general.m4:2031: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2052: AC_CACHE_CHECK is expanded from...
aclocal.m4:70: AM_PROG_AR is expanded from...
configure.ac:5: the top level
** Fix all of that:
We fix all of the described issues with a new internal m4 macro
_AM_PROG_CC_C_O (inspired to, but not based on, AC_PROG_CC_C_O) that
gets tacked on to AC_PROG_CC automatically (this is done in the
Automake-generated aclocal.m4) and that takes care of checking and
adjusting '$CC' for "-c -o" support.
The macro AM_PROG_CC_C_O is still present, but is now just a thin
wrapper around such Automake-enhanced AC_PROG_CC.
It is worth noting that the present patch causes three slight
*backward-incompatibilities*:
1. The name cache variable used by AM_PROG_CC_C_O is no longer
computed (at configure runtime!) from the content of '$CC',
but is statically defined as 'am_cv_prog_cc_c_o'.
2. 'cc' is no longer checked by AM_PROG_CC_C_O, only '$CC' is.
3. AM_PROG_CC_C_O no longer AC_DEFINE the C preprocessor symbol
'NO_MINUS_C_MINUS_O'.
Given however that the third change can easily be worked around, that
the first two changes can be legitimately seen as bug fixes, and that
the new semantics introduced by such changes will simplify the transition
to Automake 2.0 (when the 'subdir-objects' will always be enabled
unconditionally), we believe they are acceptable to be shipped with
Automake 1.14.
With this patch, we also revert some of the testsuite adjustments done
in previous commit v1.13.2-178-g9877109 of 2013-05-24 (compile: rewrite
AC_PROG_CC with AM_PROG_CC_C_O contents). Such adjustments are no longer
needed.
* m4/minuso.m4 (_AM_PROG_CC_C_O): New internal macro, basically and
adjusted version of a merge between Autoconf-provided AC_PROG_CC_C_O
and our old implementation of AM_PROG_CC_C_O.
(AM_PROG_CC_C_O): Redefine as a simple wrapper around AC_PROG_CC.
* m4/init.m4 (AC_PROG_CC): Append _AM_PROG_CC_C_O, not AM_PROG_CC_C_O,
to the pre-existing expansion of this macro.
* m4/ar-lib.m4 (AM_PROG_AR): No longer require it to be expanded after
AC_PROG_CC.
* t/aclocal-deps.sh: Move AC_PROG_CC invocation after AC_PROG_RANLIB
and AM_PROG_AR invocations. Things should work this way too (as they
used to).
* t/subobj-clean-lt-pr10697.sh: Likewise.
* t/alloca.sh: Move AC_PROG_CC invocation after AM_PROG_AR invocation.
* t/condlib.sh: Likewise.
* t/aclocal-deps.sh: Move AC_PROG_CC invocation after LT_INIT and
AM_PROG_AR invocations. Make autoconf and autoheader warnings fatal.
* t/am-prog-cc-c-o.sh: Adjust to the new semantics, enhance a little,
and reduce code duplication.
* t/ccnoco.sh: Make autoconf warnings fatal.
* t/subpkg.sh: Likewise.
* t/ccnoco-lib.sh: Likewise, and fix a comment.
* t/link_cond.sh: Enhance a couple of error messages.
* configure.ac: Drop "nullification" of AM_PROG_CC_C_O.
* NEWS: Adjust.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
9877109c
|
2013-05-14T16:08:32
|
|
compile: rewrite AC_PROG_CC with AM_PROG_CC_C_O contents
This is a much simpler rewrite than the one we attempted in the past,
and that was later removed by commit 'v1.13.1d-137-g32eb770' of
2013-05-11 (compile: avoid AC_PROG_CC messy rewrite).
Not only this change simplifies the code a little, but has the welcome
collateral effect of making automatic dependency tracking work better
with compilers that doesn't grasp the '-c' and '-o' options together.
Issues in that setup have been caught by several failures in the target
'check-no-cc-c-o'.
Unfortunately, this change has less welcome collateral effects:
1. AM_PROG_AR must now be called *after* AC_PROG_CC;
2. Autoconf emits extra warnings when used with Automake-generated
aclocal.m4.
These are unacceptable regressions for a release, but since we are
going to fix them soon enough in a follow-up patch (surely to be
applied before Automake 1.14 is released) we don't worry too much.
* m4/init.m4: Redefine AC_PROG_CC early, to automatically invoke
AM_PROG_CC_C_O as well. Accordingly, drop now-unneeded "automagical"
AM_PROG_CC_C_O expansion at later time (which took place thanks to
a AC_CONFIG_COMMANDS_PRE call).
* m4/minuso.m4 (AM_PROG_CC_C_O): Ensure the expansion of the body
of this macro takes place with C as "current Autoconf language" (use
AC_LANG_PUSH/AC_LANG_POP).
* m4/ar-lib.m4 (AM_PROG_AR): Likewise. Also, require this macro to
be expanded *after* AC_PROG_CC (so that any rewrite of $CC, if required,
has already taken place).
* t/add-missing.tap: Adjust to avoid spurious failures.
* t/aclocal-deps.sh: Likewise, by having AM_PROG_AR called *after*
AC_PROG_CC.
* t/subobj-clean-lt-pr10697.sh: Likewise.
* t/alloca.sh: Likewise.
* t/condlib.sh: Likewise.
* t/discover.sh: Likewise.
* t/objc-megademo.sh: Likewise.
* t/ccnoco.sh: Extend a little.
* t/ccnoco-deps.sh: New test.
* t/ccnoco-lib.sh: Likewise.
* t/ccnoco-lt.sh: Likewise.
* t/list-of-tests.mk: Add them.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
7df8b28c
|
2012-12-31T18:18:37
|
|
maint: update copyright year for 2013 (in branch maint)
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
6e3c0b92
|
2012-07-14T18:49:25
|
|
m4: get rid of "# serial" lines
The "#serial" lines are only considered by aclocal for the system-wide
third-party '.m4' files, not for the Automake-provided ones. So they
serve no real purpose in the Automake '.m4' files.
In addition, now that we use git and topic branches, and that we are also
writing the Automake-NG fork, the "#serial" lines are becoming more and
more unreliable (e.g., different version of the same file in different
branches can easily end up having the same serial numbers).
So let's just nuke all the "#serial" lines. See also automake bug#11932.
* m4/*.m4: All "# serial" lines removed.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
|
|
|
641a5a4b
|
2012-02-16T10:46:23
|
|
maint: run "make update-copyright"
|
|
|
eea57793
|
2011-11-05T21:35:40
|
|
ar-lib: fix configure output for "unrecognized archiver interface"
* m4/ar-lib.m4: Ensure that, even when an error is hit while trying
to determine the archiver interface kind, the "checking archiver
interface" message from configure is properly terminated before
an error message is printed, to avoid slightly garbled output.
* tests/ar4.test: Enhance.
* tests/ar5.test: Likewise.
|
|
c7a6a92e
|
2011-10-21T00:23:34
|
|
ar-lib: new 'AM_PROG_AR' macro, triggering the 'ar-lib' script
* m4/ar-lib.m4: New macro AM_PROG_AR, which locates an
archiver and triggers the auxiliary 'ar-lib' script if needed.
* m4/Makefile.am (dist_m4data_DATA): Update.
* automake.in ($seen_ar): New variable.
(scan_autoconf_traces): Set it.
(handle_libraries, handle_ltlibraries): Require AM_PROG_AR for
portability.
* doc/automake.texi (Public Macros): Mention the new
'AM_PROG_AR' macro.
(Subpackages): Add AM_PROG_AR to the example.
(A Library): Adjust recommendations for AR given the new
AM_PROG_AR macro.
* All relevant tests: Adjust to new portability requirements due
to the new AM_PROG_AR macro.
* tests/ar-lib2.test: New test, checking that AM_PROG_AR triggers
install of ar-lib.
* tests/ar-lib3.test: New test, checking that lib_LIBRARIES
requires AM_PROG_AR.
* tests/ar-lib4.test: New test, checking that lib_LTLIBRARIES
requires AM_PROG_AR.
* tests/ar-lib5a.test: New test, checking that AM_PROG_AR triggers
use of ar-lib when the archiver is Microsoft lib.
* tests/ar-lib5b.test: New test, checking that AM_PROG_AR triggers
use of ar-lib when the archiver is a faked lib.
* tests/ar-lib6a.test: New test, checking the ordering of
AM_PROG_AR and LT_INIT.
* tests/ar-lib6b.test: New test, checking the ordering of
AM_PROG_AR and AC_PROG_LIBTOOL.
* tests/ar-lib7.test: New test, checking that automake warns
if ar-lib is missing.
* tests/ar3.test: New test, checking that AR and ARFLAGS may
be overridden by the user even if AM_PROG_AR is used.
* tests/ar4.test: New test, checking that AM_PROG_AR bails out
if it cannot determine the archiver interface.
* tests/ar5.test: New test, checking that AM_PROG_AR runs its
optional argument if it cannot determine the archiver interface.
* tests/defs.in: New required entry 'lib'.
* tests/Makefile.am (TESTS): Update.
* NEWS: Update.
Signed-off-by: Peter Rosin <peda@lysator.liu.se>
|