-
Notifications
You must be signed in to change notification settings - Fork 1
/
NEWS
3062 lines (2326 loc) · 126 KB
/
NEWS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
New in 2.0:
* Compilation and object files:
- If a source file is placed in a subdirectory, the corresponding compiled
object will *always* be put into the subdirectory named after the source
file, rather than in the current directory. For instance, 'src/file.c'
and 'src/file.f90' will be compiled to 'src/file.o', and 'sub/dir/mu.cc'
will be compiled to 'sub/dir/mu.o'. Put in another way, Automake 2.0
and later will *unconditionally* behave as older Automake versions did
when the 'subdir-objects' option was given.
* Texinfo support:
- Automake used to implement an undocumented hack causing '.info' files
that appeared to be cleaned (by e.g. being listed in the CLEANFILES
variable) to also be built in the builddir rather than in the srcdir;
this was for backward compatibility with packages such as Texinfo,
which did things like:
info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
DISTCLEANFILES = texinfo texinfo-* info*.info*
# Do not create info files for distribution.
dist-info:
@:
in order not to distribute .info files.
Now that we have the 'info-in-builddir' option that explicitly causes
generated '.info' files to be placed in the builddir, this hack is no
longer necessary. We have thus removed\ it.
* Aclocal search path:
- Third-party m4 files located in the system-wide aclocal directory,
as well as in any directory listed in the ACLOCAL_PATH environment
variable, now take precedence over "built-in" Automake macros.
For example, assuming Automake is installed in the '/usr/local'
hierarchy, a definition of the AM_PROG_VALAC macro found in file
(say) '/usr/local/share/aclocal/my-vala.m4' should take precedence
over the same-named automake-provided macro, as defined in file
'/usr/local/share/aclocal-2.0/vala.m4'.
* Obsolescent features flagged:
- Use of the special makefile variable 'ACLOCAL_AMFLAGS' is deprecated.
To specify locations of extra m4 files, the 'AC_CONFIG_MACRO_DIR' or
'AC_CONFIG_MACRO_DIRS' (the latter introduced with autoconf 2.70)
should be used instead. And use of the '--install' aclocal option in
'ACLOCAL_AMFLAGS' has proved to be a bad idea anyway -- see automake
bug#9037.
* Obsolete features removed:
- Support for the long-deprecated name 'configure.in' for the Autoconf
input file has been removed altogether. Just use the modern name
'configure.ac' instead.
- Support for the long-obsolete variable $(ACLOCAL_M4_SOURCES) has
been removed. It should be safe to simply remove any definition
of it you have in your Makefiles.
* Removed support for obsolete platforms:
- Support for automatic dependency tracking with the SGI C/C++ compilers
on IRIX has been removed. The SGI depmode had been reported broken
"in the wild" already, and we don't think investing time in debugging
and fixing it would have been worthwhile, especially considering that
SGI has last updated those compilers in 2006, and is expected to retire
support for them in December 2013:
<http://www.sgi.com/services/support/irix_mips_support.html>
- Support for DJGPP on MS-DOS and/or Windows 95/98/ME has been removed.
Note that both Cygwin and MSYS/MinGW on modern Windows versions will
continue to be fully supported.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* WARNING: Future backward-incompatibilities!
- Makefile recipes generated by Automake 2.0 will expect to use an
'rm' program that doesn't complain when called without any non-option
argument if the '-f' option is given (so that commands like "rm -f"
and "rm -rf" will act as a no-op, instead of raising usage errors).
This behavior of 'rm' is very widespread in the wild, and it will be
required in the next POSIX version:
<http://austingroupbugs.net/view.php?id=542>
Accordingly, AM_INIT_AUTOMAKE now expands some shell code that checks
that the default 'rm' program in PATH satisfies this requirement,
aborting the configure process if this is not the case. For the
moment, it's still possible to force the configuration process to
succeed even with a broken 'rm', that that will no longer be the case
for Automake 2.0.
- Automake 2.0 will require Autoconf 2.70 or later (which is still
unreleased at the moment of writing, but is planned to be released
before Automake 2.0 is).
- Automake 2.0 will drop support for the long-deprecated 'configure.in'
name for the Autoconf input file. You are advised to start using the
recommended name 'configure.ac' instead, ASAP.
- The ACLOCAL_AMFLAGS special make variable will be fully deprecated in
Automake 2.0: it will raise warnings in the "obsolete" category (but
still no hard error of course, for compatibilities with the many, many
packages that still relies on that variable). You are advised to
start relying on the new Automake support for AC_CONFIG_MACRO_DIRS
instead (which was introduced in Automake 1.13).
- Automake 2.0 will remove support for automatic dependency tracking
with the SGI C/C++ compilers on IRIX. The SGI depmode has been
reported broken "in the wild" already, and we don't think investing
time in debugging and fixing is worthwhile, especially considering
that SGI has last updated those compilers in 2006, and retired
support for them in December 2013:
<http://www.sgi.com/services/support/irix_mips_support.html>
- Automake 2.0 will remove support for MS-DOS and Windows 95/98/ME
(support for them was offered by relying on the DJGPP project).
Note however that both Cygwin and MSYS/MinGW on modern Windows
versions will continue to be fully supported.
- Automake-provided scripts and makefile recipes might (finally!)
start assuming a POSIX shell in Automake 2.0. There still is no
certainty about this though: we'd first like to wait and see
whether future Autoconf versions will be enhanced to guarantee
that such a shell is always found and provided by the checks in
./configure.
- Starting from Automake 2.0, third-party m4 files located in the
system-wide aclocal directory, as well as in any directory listed
in the ACLOCAL_PATH environment variable, will take precedence
over "built-in" Automake macros. For example (assuming Automake
is installed in the /usr/local hierarchy), a definition of the
AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
should take precedence over the same-named automake-provided macro
(defined in '/usr/local/share/aclocal-2.0/vala.m4').
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.16:
* Bugs fixed:
- Automatic dependency tracking has been fixed to work also when the
'subdir-object' option is used and some 'foo_SOURCES' definition
contains unexpanded references to make variables, as in, e.g.:
a_src = sources/libs/aaa
b_src = sources/bbb
foo_SOURCES = $(a_src)/bar.c $(b_src)/baz.c
With such a setup, the created makefile fragment containing dependency
tracking information will be correctly placed under the directories
named 'sources/libs/aaa/.deps' and 'sources/bbb/.deps', rather than
mistakenly under directories named (literally!) '$(src_a)/.deps' and
'$(src_b)/.deps' (this was the first part of automake bug#13928).
Notice that in order to fix this bug we had to slightly change the
semantics of how config.status bootstraps the makefile fragments
required for the dependency tracking to work: rather than attempting
to parse the Makefiles via grep and sed trickeries only, we actually
invoke 'make' on a slightly preprocessed version of those Makefiles,
using a private target that is only meant to bootstrap the required
makefile fragments.
- The 'subdir-object' option no longer causes object files corresponding
to source files specified with an explicit '$(srcdir)' component to be
placed in the source tree rather than in the build tree.
For example, if Makefile.am contains:
AUTOMAKE_OPTIONS = subdir-objects
foo_SOURCES = $(srcdir)/foo.c $(srcdir)/s/bar.c $(top_srcdir)/baz.c
then "make all" will create 'foo.o' and 's/bar.o' in $(builddir) rather
than in $(srcdir), and will create 'baz.o' in $(top_builddir) rather
than in $(top_srcdir).
This was the second part of automake bug#13928.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.15.1:
* Miscellaneous changes:
- Support the Windows version of the Intel C Compiler (icl) in the
'compile' script in the same way the (compatible) Microsoft C Compiler
is supported.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.15:
* Improvements and refactorings in the install-sh script:
- It has been modernized, and now makes the following assumptions
*unconditionally*:
(1) a working 'dirname' program is available;
(2) the ${var:-value} shell parameters substitution works;
(3) the "set -f" and "set +f" shell commands work, and, respectively,
disable and enable shell globbing.
- The script implements stricter error checking, and now it complains
and bails out if any of the following expectations is not met:
(1) the options -d and -t are never used together;
(2) the argument passed to option -t is a directory;
(3) if there are two or more SOURCEFILE arguments, the
DESTINATION argument must be a directory.
* Automake-generated testsuites:
- The default test-driver used by the Automake-generated testsuites
now appends the result and exit status of each "plain" test to the
associated log file (automake bug#11814).
- The perl implementation of the TAP testsuite driver is no longer
installed in the Automake's scripts directory, and is instead just
distributed as a "contrib" addition. There should be no reason to
use this implementation anyway in real packages, since the awk+shell
implementation of the TAP driver (which is documented in the manual)
is more portable and has feature parity with the perl implementation.
- The rule generating 'test-suite.log' no longer risk incurring in an
extra useless "make all" recursive invocation in some corner cases
(automake bug#16302).
* Distribution:
- Automake bug#18286: "make distcheck" could sometimes fail to detect
files missing from the distribution tarball, especially in those cases
where both the generated files and their dependencies are explicitly
in $(srcdir). An important example of this are *generated* makefile
fragments included at Automake time in Makefile.am; e.g.:
...
$(srcdir)/fragment.am: $(srcdir)/data.txt $(srcdir)/preproc.sh
cd $(srcdir) && $(SHELL) preproc.sh <data.txt >fragment.am
include $(srcdir)/fragment.am
...
If the use forgot to add data.txt and/or preproc.sh in the distribution
tarball, "make distcheck" would have erroneously succeeded! This issue
is now fixed.
- As a consequence of the previous change, "make distcheck" will run
using '$(distdir)/_build/sub' as the build directory, rather than
simply '$(distdir)/_build' (as it was the case for Automake 1.14 and
earlier). Consequently, the './configure' and 'make' invocations
issued by the distcheck recipe now have $(srcdir) equal to '../..',
rather than to just '..'. Dependent and similar variables (e.g.,
'$(top_srcdir)') are also changed accordingly.
Thus, Makefiles that made assumptions about the exact values of the
build and source directories used by "make distcheck" will have to
be adjusted. Notice that making such assumptions was a bad and
unsupported practice anyway, since the exact locations of those
directories should be considered implementation details, and we
reserve the right to change them at any time.
* Miscellaneous bugs fixed:
- The expansion of AM_INIT_AUTOMAKE ends once again with a trailing
newline (bug#16841). Regression introduced in Automake 1.14.
- We no longer risk to use '$ac_aux_dir' before it's defined (see
automake bug#15981). Bug introduced in Automake 1.14.
- The code used to detect whether the currently used make is GNU make
or not (relying on the private macro 'am__is_gnu_make') no longer
risks causing "Arg list too long" for projects using automatic
dependency tracking and having a ton of source files (bug#18744).
- Automake tries to offer a more deterministic output for generated
Makefiles, in the face of the newly-introduced randomization for
hash keys order in Perl 5.18.
- In older Automake versions, if a user defined one single Makefile
fragment (say 'foo.am') to be included via Automake includes in
his main Makefile.am, and defined a custom make rule to generate that
file from other data, Automake used to spuriously complain with some
message like "... overrides Automake target '$(srcdir)/foo.am".
This bug is now fixed.
- The user can now extend the special .PRECIOUS target, the same way
he could already do with the .MAKE .and .PHONY targets.
- Some confusing typos have been fixed in the manual and in few warning
messages (automake bug#16827 and bug#16997).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.14.1:
* Bugs fixed:
- The user is no longer allowed to override the --srcdir nor the --prefix
configure options used by "make distcheck" (bug#14991).
- Fixed a gross inefficiency in the recipes for installing byte-compiled
python files, that was causing an O(N^2) performance on the number N of
files, instead of the expected O(N) performance. Note that this bug
was only relevant when the number of python files was high (which is
unusual in practice).
- Automake try to offer a more deterministic output for warning messages,
in the face of the newly-introduced randomization for hash keys order
in Perl 5.18.
- The 'test-driver' script now actually error out with a clear error
message on the most common invalid usages.
- Several spurious failures/hangs in the testsuite (bugs #14706, #14707,
#14760, #14911, #15181, #15237).
* Documentation fixes:
- Fixed typos in the 'fix-timestamp.sh' example script that made it
nonsensical.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.14:
* C compilation, and the AC_PROG_CC and AM_PROG_CC_C_O macros:
- The 'compile' script is now unconditionally required for all packages
that perform C compilation (if you are using the '--add-missing'
option, automake will fetch that script for you, so you shouldn't
need any explicit adjustment). This new behaviour is needed to avoid
obscure errors when the 'subdir-objects' option is used, and the
compiler is an inferior one that doesn't grasp the combined use of
both the "-c -o" options; see discussion about automake bug#13378 for
more details:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>
- The next major Automake version (2.0) will unconditionally activate
the 'subdir-objects' option. In order to smooth out the transition,
we now give a warning (in the category 'unsupported') whenever a
source file is present in a subdirectory but the 'subdir-object' is
not enabled. For example, the following usage will trigger such a
warning:
bin_PROGRAMS = sub/foo
sub_foo_SOURCES = sub/main.c sub/bar.c
- Automake will automatically enhance the autoconf-provided macro
AC_PROG_CC to force it to check, at configure time, that the
C compiler supports the combined use of both the '-c' and '-o'
options. The result of this check is saved in the cache variable
'am_cv_prog_cc_c_o', and said result can be overridden by
pre-defining that variable.
- The AM_PROG_CC_C_O macro can still be called, albeit that should no
longer be necessary. This macro is now just a thin wrapper around the
Automake-enhanced AC_PROG_CC. This means, among the other things,
that its behaviour is changed in three ways:
1. It no longer invokes the Autoconf-provided AC_PROG_CC_C_O
macro behind the scenes.
2. It caches the check result in the 'am_cv_prog_cc_c_o' variable,
and not in a 'ac_cv_prog_cc_*_c_o' variable whose exact name is
dynamically computed only at configure runtime (really!) from
the content of the '$CC' variable.
3. It no longer automatically AC_DEFINE the C preprocessor
symbol 'NO_MINUS_C_MINUS_O'.
* Texinfo support:
- Automake can now be instructed to place '.info' files generated from
Texinfo input in the builddir rather than in the srcdir; this is done
specifying the new automake option 'info-in-builddir'. This feature
was requested by the developers of GCC, GDB, GNU binutils and the GNU
bfd library. See the extensive discussion about automake bug#11034
for more details.
- For quite a long time, Automake has been implementing an undocumented
hack which ensured that '.info' files which appeared to be cleaned
(by being listed in the CLEANFILES or DISTCLEANFILES variables) were
built in the builddir rather than in the srcdir; this hack was
introduced to ensure better backward-compatibility with package
such as Texinfo, which do things like:
info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
DISTCLEANFILES = texinfo texinfo-* info*.info*
# Do not create info files for distribution.
dist-info:
@:
in order not to distribute generated '.info' files.
Now that we have the 'info-in-builddir' option that explicitly causes
generated '.info' files to be placed in the builddir, this hack should
be longer necessary, so we deprecate it with runtime warnings.
It will be removed altogether in Automake 2.0.
* Relative directory in Makefile fragments:
- The special Automake-time substitutions '%reldir%' and '%canon_reldir%'
(and their short versions, '%D%' and '%C%' respectively) can now be used
in an included Makefile fragment. The former is substituted with the
relative directory of the included fragment (compared to the top-level
including Makefile), and the latter with the canonicalized version of
the same relative directory.
# in 'Makefile.am':
bin_PROGRAMS = # will be updated by included Makefile fragments
include src/Makefile.inc
# in 'src/Makefile.inc':
bin_PROGRAMS += %reldir%/foo
%canon_reldir%_foo_SOURCES = %reldir%/bar.c
This should be especially useful for packages using a non-recursive
build system.
* Deprecated distribution formats:
- The 'shar' and 'compress' distribution formats are deprecated, and
scheduled for removal in Automake 2.0. Accordingly, the use of the
'dist-shar' and 'dist-tarZ' will cause warnings at automake runtime
(in the 'obsolete' category), and the recipes of the Automake-generated
targets 'dist-shar' and 'dist-tarZ' will unconditionally display
(non-fatal) warnings at make runtime.
* New configure runtime warnings about "rm -f" support:
- To simplify transition to Automake 2.0, the shell code expanded by
AM_INIT_AUTOMAKE now checks (at configure runtime) that the default
'rm' program in PATH doesn't complain when called without any
non-option argument if the '-f' option is given (so that commands like
"rm -f" and "rm -rf" act as a no-op, instead of raising usage errors).
If this is not the case, the configure script is aborted, to call the
attention of the user on the issue, and invite him to fix his PATH.
The checked 'rm' behavior is very widespread in the wild, and will be
required by future POSIX versions:
<http://austingroupbugs.net/view.php?id=542>
The user can still force the configure process to complete even in the
presence of a broken 'rm' by defining the ACCEPT_INFERIOR_RM_PROGRAM
environment variable to "yes". And the generated Makefiles should
still work correctly even when such broken 'rm' is used. But note
that this will no longer be the case with Automake 2.0 though, so, if
you encounter the warning, please report it to us ASAP (and try to fix
your environment as well).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13.4:
* Bugs fixed:
- Fix a minor regression introduced in Automake 1.13.3: when two or more
user-defined suffix rules were present in a single Makefile.am,
automake would needlessly include definition of some make variables
related to C compilation in the generated Makefile.in (bug#14560).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13.3:
* Documentation fixes:
- The documentation no longer mistakenly reports that the obsolete
'AM_MKDIR_PROG_P' macro and '$(mkdir_p)' make variable are going
to be removed in Automake 2.0.
* Bugs fixed:
- Byte-compilation of Emacs lisp files could fail spuriously on
Solaris, when /bin/ksh or /usr/xpg4/bin/sh were used as shell.
- If the same user-defined suffixes were transformed into different
Automake-known suffixes in different Makefile.am files in the same
project, automake could get confused and generate inconsistent
Makefiles (automake bug#14441).
For example, if 'Makefile.am' contained a ".ext.cc:" suffix rule,
and 'sub/Makefile.am' contained a ".ext.c:" suffix rule, automake
would have mistakenly placed into 'Makefile.in' rules to compile
"*.c" files into object files, and into 'sub/Makefile.in' rules to
compile "*.cc" files into object files --- rather than the other
way around. This is now fixed.
* Testsuite work:
- The test cases no longer have the executable bit set. This should
make it clear that they are not meant to be run directly; as
explained in t/README, they can only be run through the custom
'runtest' script, or by a "make check" invocation.
- The testsuite has seen the introduction of a new helper function
'run_make', and several related changes. These serve a two-fold
purpose:
1. Remove brittleness due to the use of "make -e" in test cases.
2. Seamlessly allow the use of parallel make ("make -j...") in the
test cases, even where redirection of make output is involved
(see automake bug#11413 for a description of the subtle issues
in this area).
- Several spurious failures have been fixed (they hit especially
MinGW/MSYS builds). See automake bugs #14493, #14494, #14495,
#14498, #14499, #14500, #14501, #14517 and #14528.
- Some other minor miscellaneous changes and fixlets.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13.2:
* Documentation fixes:
- The long-deprecated but still supported two-arguments invocation form
of AM_INIT_AUTOMAKE is documented once again. This seems the sanest
thing to do, given that support for such usage might need to remain
in place for an unspecified amount of time in order to cater to people
who want to define the version number for their package dynamically at
configure runtime (unfortunately, Autoconf does not yet support this
scenario, so we cannot delegate the work to it).
- The serial testsuite harness is no longer reported as "deprecated",
but as "discouraged". We have no plan to remove it, nor to make its
use cause runtime warnings.
- The parallel testsuite is no longer reported as "experimental"; it
is well tested, and should be stable now.
- The 'shar' and 'tarZ' distribution formats and the 'dist-shar' and
'dist-tarZ' options are obsolescent, and their use is deprecated
in the documentation.
- Other minor miscellaneous fixes and improvements; in particular,
some improvements in cross-references.
* Obsolescent features:
- Use of suffix-less info files (that can be specified through the
'@setfilename' macro in Texinfo input files) is discouraged, and
its use will raise warnings in the 'obsolete' category. Simply
use the '.info' extension for all your info files, transforming
usages like:
@setfilename myprogram
into:
@setfilename myprogram.info
- Use of Texinfo input files with '.txi' or '.texinfo' extensions
is discouraged, and its use will raise warnings in the 'obsolete'
category. You are advised to simply use the '.texi' extension
instead.
* Bugs fixed:
- When the 'ustar' option is used, the generated configure script no
longer risks hanging during the tests for the availability of the
'pax' utility, even if the user running configure has a UID or GID
that requires more than 21 bits to be represented.
See automake bug#8343 and bug#13588.
- The obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC work once
again, as they did in Automake 1.12.x (albeit printing runtime
warnings in the 'obsolete' category). Removing them has turned
out to be a very bad idea, because it complicated distro packing
enormously. Making them issue fatal warnings, as we did in
Automake 1.13, has turned out to be a similarly very bad idea,
for exactly the same reason.
- aclocal will no longer error out if the first local m4 directory
(as specified by the '-I' option or the 'AC_CONFIG_MACRO_DIRS' or
'AC_CONFIG_MACRO_DIR' macros) doesn't exist; it will merely report
a warning in the 'unsupported' category. This is done to support
some pre-existing real-world usages. See automake bug#13514.
- aclocal will no longer consider directories for extra m4 files more
than once, even if they are specified multiple times. This ensures
packages that specify both
AC_CONFIG_MACRO_DIR([m4]) in configure.ac
ACLOCAL_AMFLAGS = -I m4 in Makefile.am
will work correctly, even when the 'm4' directory contains no
package-specific files, but is used only to install third-party
m4 files (as can happen with e.g., "libtoolize --install").
See automake bug#13514.
- Analysis of make flags in Automake-generated rules has been made more
robust, and more future-proof. For example, in presence of make that
(like '-I') take an argument, the characters in said argument will no
longer be spuriously considered as a set of additional make options.
In particular, automake-generated rules will no longer spuriously
believe to be running in dry mode ("make -n") if run with an invocation
like "make -I noob"; nor will they believe to be running in keep-going
mode ("make -k") if run with an invocation like "make -I kool"
(automake bug#12554).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13.1:
* Bugs fixed:
- Use of the obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC now
causes a clear and helpful error message, instead of obscure ones
(issue introduced in Automake 1.13).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.13:
* Bugs fixed:
- ylwrap renames properly header guards in generated header files
(*.h), instead of leaving Y_TAB_H.
- ylwrap now also converts header guards in implementation files
(*.c). Because ylwrap failed to rename properly #include in the
implementation files, current versions of Bison (e.g., 2.7)
duplicate the generated header file in the implementation file.
The header guard then protects the implementation file from
duplicate definitions from the header file.
* Version requirements:
- Autoconf 2.65 or greater is now required.
- The rules to build PDF and DVI output from Texinfo input now
require Texinfo 4.9 or later.
* Obsolete features:
- Support for the "Cygnus-style" trees (once enabled by the 'cygnus'
option) has been removed. See discussion about automake bug#11034
for more background: <http://debbugs.gnu.org/11034>.
- The deprecated aclocal option '--acdir' has been removed. You
should use the options '--automake-acdir' and '--system-acdir'
instead (which have been introduced in Automake 1.11.2).
- The following long-obsolete m4 macros have been removed:
AM_PROG_CC_STDC: superseded by AC_PROG_CC since October 2002
fp_PROG_CC_STDC: broken alias for AM_PROG_CC_STDC
fp_WITH_DMALLOC: old alias for AM_WITH_DMALLOC
AM_CONFIG_HEADER: superseded by AC_CONFIG_HEADERS since July 2002
ud_PATH_LISPDIR: old alias for AM_PATH_LISPDIR
jm_MAINTAINER_MODE: old alias for AM_MAINTAINER_MODE
ud_GNU_GETTEXT: old alias for AM_GNU_GETTEXT
gm_PROG_LIBTOOL: old alias for AC_PROG_LIBTOOL
fp_C_PROTOTYPES: old alias for AM_C_PROTOTYPES (which was part
of the now-removed automatic de-ANSI-fication
support of Automake)
- All the "old alias" macros in 'm4/obsolete.m4' have been removed.
- Use of the long-deprecated two- and three-arguments invocation forms
of the AM_INIT_AUTOMAKE is no longer documented. It's still supported
though (albeit with a warning in the 'obsolete' category), to cater
for people who want to define the version number for their package
dynamically (e.g., from the current VCS revision). We'll have to
continue this support until Autoconf itself is fixed to allow better
support for such dynamic version numbers.
* Elisp byte-compilation:
- The byte compilation of '.el' files into '.elc' files is now done
with a suffix rule. This has simplified the compilation process, and
more importantly made it less brittle. The downside is that emacs is
now invoked once for each '.el' files, which cause some noticeable
slowdowns. These should however be mitigated on multicore machines
(which are becoming the norm today) if concurrent make ("make -j")
is used.
- Elisp files placed in a subdirectory are now byte-compiled to '.elc'
files in the same subdirectory; for example, byte-compiling of file
'sub/foo.el' file will result in 'sub/foo.elc' rather than in
'foo.elc'. This behaviour is backward-incompatible with older
Automake versions, but it is more natural and more sane. See also
automake bug#7441.
- The Emacs invocation performing byte-compilation of '.el' files honors
the $(AM_ELCFLAGS) and $(ELCFLAGS) variables; as typical, the former
one is developer-reserved and the latter one user-reserved.
- The 'elisp-comp' script, once provided by Automake, has been rendered
obsoleted by the just-described changes, and thus removed.
* Changes to Automake-generated testsuite harnesses:
- The parallel testsuite harness (previously only enabled by the
'parallel-tests' option) is the default one; the older serial
testsuite harness will still be available through the use of the
'serial-tests' option (introduced in Automake 1.12).
- The 'color-tests' option is now unconditionally activated by default.
In particular, this means that testsuite output is now colorized by
default if the attached terminal seems to support ANSI escapes, and
that the user can force output colorization by setting the variable
AM_COLOR_TESTS to "always". The 'color-tests' is still recognized
for backward-compatibility, although it's a handled as a no-op now.
* Silent rules support:
- Support for silent rules is now always active in Automake-generated
Makefiles. So, although the verbose output is still the default,
the user can now always use "./configure --enable-silent-rules" or
"make V=0" to enable quieter output in the package he's building.
- The 'silent-rules' option has now become a no-op, preserved for
backward-compatibility only. In particular, its use no longer
disables the warnings in the 'portability-recursive' category.
* Texinfo Support:
- The rules to build PDF and DVI files from Texinfo input now require
Texinfo 4.9 or later.
- The rules to build PDF and DVI files from Texinfo input now use the
'--build-dir' option, to keep the auxiliary files used by texi2dvi
and texi2pdf around without cluttering the build directory, and to
make it possible to run the "dvi" and "pdf" recipes in parallel.
* Automatic remake rules and 'missing' script:
- The 'missing' script no longer tries to update the timestamp of
out-of-date files that require a maintainer-specific tool to be
remade, in case the user lacks such a tool (or has a too-old version
of it). It just gives a useful warning, and in some cases also a
tip about how to obtain such a tool.
- The missing script has thus become useless as a (poor) way to work
around the sketched-timestamps issues that can happen for projects
that keep generated files committed in their VCS repository. Such
projects are now encouraged to write a custom "fix-timestamps.sh"
script to avoid such issues; a simple example is provided in the
"CVS and generated files" chapter of the automake manual.
* Recursive targets:
- The user can now define his own recursive targets that recurse
in the directories specified in $(SUBDIRS). This can be done by
specifying the name of such targets in invocations of the new
'AM_EXTRA_RECURSIVE_TARGETS' m4 macro.
* Tags:
- Any failure in the recipe of the "tags", "ctags", "cscope" or
"cscopelist" targets in a subdirectory is now propagated to the
top-level make invocation.
- Tags are correctly computed also for files in _SOURCES variables that
only list files with non-standard suffixes (see automake bug#12372).
* Improvements to aclocal and related rebuilds rules:
- Autoconf-provided macros AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS
are now traced by aclocal, and can be used to declare the local m4
include directories. Formerly, one had to specify it with an explicit
'-I' option to the 'aclocal' invocation.
- The special make variable ACLOCAL_AMFLAGS is deprecated; future
Automake versions will warn about its use, and later version will
remove support for it altogether.
* The depcomp script:
- Dropped support for libtool 1.4.
- Various internal refactorings. They should cause no visible change,
but the chance for regression is there anyway, so please report any
unexpected or suspicious behaviour.
- Support for pre-8.0 versions of the Intel C Compiler has been dropped.
This should cause no problem, since icc 8.0 has been released in
December 2003 -- almost nine years ago.
- Support for tcc (the Tiny C Compiler) has been improved, and is now
handled through a dedicated 'tcc' mode.
* The ylwrap script:
- ylwrap generates header guards with a single '_' for series of non
alphabetic characters, instead of several. This is what Bison >=
2.5.1 does.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Bugs fixed in 1.12.6:
* Python-related bugs:
- The default installation location for python modules has been improved
for Python 3 on Debian and Ubuntu systems, changing from:
${prefix}/lib/python3/dist-packages
to
${prefix}/lib/python3.x/site-packages
This change should ensure modules installed using the default ${prefix}
"/usr/local" are found by default by system python 3.x installations.
See automake bug#10227.
- Python byte-compilation supports the new layout mandated by PEP-3147,
with its __pycache__ directory (automake bug#8847).
* Build system issues:
- The maintainer rebuild rules for Makefiles and aclocal.m4 in
Automake's own build system works correctly again (bug introduced
in Automake 1.12.5).
* Testsuite issues:
- The Vala-related tests has been changed to adjust to the removal of
the 'posix' profile in the valac compiler. See automake bug#12934
a.k.a. bug#12522.
- Some spurious testsuite failures related to older tools and systems
have been fixed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.12.5:
* Vala support:
- The AM_PROG_VALAC macro has been enhanced to takes two further
optional arguments; it's signature now being
AM_PROG_VALAC([MINIMUM-VERSION], [ACTION-IF-FOUND],
[ACTION-IF-NOT-FOUND])
- By default, AM_PROG_VALAC no longer aborts the configure invocation
if the Vala compiler found is too old, but simply prints a warning
messages (as it did when the Vala compiler was not found). This
should avoid unnecessary difficulties for end users that just want
to compile the unmodified, distributed Vala-generated C sources,
but happens to have an old Vala compiler in their PATH. This fixes
automake bug#12688.
- If no proper Vala compiler is found at configure runtime, AM_PROG_VALAC
will set the AC_SUBST'd variable 'VALAC' to 'valac' rather than to ':'.
This is a better default, because with it a triggered makefile rule
invoking a Vala compilation will clearly fail with an informative error
message like "valac: command not found", rather than silently, with
the error possibly going unnoticed or triggering harder-to-diagnose
fallout failures in later steps.
* Miscellaneous changes:
- automake and aclocal no longer honours the 'perllibdir' environment
variable. That had always been intended only as an hack required in
the testsuite, not meant for any use beyond that.
Bugs fixed in 1.12.5:
* Long-standing bugs:
- Automake no longer generates spurious remake rules invoking autoheader
to regenerate the template corresponding to header files specified after
the first one in AC_CONFIG_HEADERS (automake bug#12495).
- When wrapping Microsoft tools, the 'compile' script falls back to
finding classic 'libname.a' style libraries when 'name.lib' and
'name.dll.lib' aren't available.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.12.4:
* Warnings and deprecations:
- Warnings in the 'obsolete' category are enabled by default both in
automake and aclocal.
* Miscellaneous changes:
- Some testsuite weaknesses and spurious failures have been fixed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.12.3:
* Miscellaneous changes:
- The '.m4' files provided by Automake no longer define serial numbers.
This should cause no difference in the behaviour of aclocal though.
- Some testsuite weaknesses and spurious failures have been fixed.
- There is initial support for automatic dependency tracking with the
Portland Group C/C++ compilers, thanks to the new new depmode 'pgcc'.
Bugs fixed in 1.12.3:
* Long-standing bugs:
- Instead of renaming only self-references of files (typically for
#lines), ylwrap now also renames references to the other generated
files. This fixes support for GLR and C++ parsers from Bison (PR
automake/491 and automake bug#7648): 'parser.c' now properly
#includes 'parser.h' instead of 'y.tab.h'.
- Generated files unknown to ylwrap are now preserved. This fixes
C++ support for Bison (automake bug#7648): location.hh and the
like are no longer discarded.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.12.2:
* Warnings and deprecations:
- Automake now issues a warning (in the 'portability' category) if
'configure.in' is used instead of 'configure.ac' as the Autoconf
input file. Such a warning will also be present in the next
Autoconf version (2.70).
* Cleaning rules:
- Recursive cleaning rules descends into the $(SUBDIRS) in the natural
order (as done by the other recursive rules), rather than in the
inverse order. They used to do that in order to work a round a
limitation in an older implementation of the automatic dependency
tracking support, but that limitation had been lifted years ago
already, when the automatic dependency tracking based on side-effects
of compilation had been introduced.
- Cleaning rules for compiled objects (both "plain" and libtool) work
better when subdir objects are involved, not triggering a distinct
'rm' invocation for each such object. They do so by removing *any*
compiled object file that is in the same directory of a subdir
object. See automake bug#10697.
* Silent rules support:
- A new predefined $(AM_V_P) make variable is provided; it expands
to a shell conditional that can be used in recipes to know whether
make is being run in silent or verbose mode.
Bugs fixed in 1.12.2:
* SECURITY VULNERABILITIES!
- The 'distcheck' recipe no longer grants temporary world-write
permissions on the extracted distdir. Even if such rights were
only granted for a vanishingly small time window, the implied
race condition proved to be enough to allow a local attacker
to run arbitrary code with the privileges of the user running
"make distcheck". This is CVE-2012-3386.
* Long-standing bugs:
- The "recheck" targets behaves better in the face of build failures
related to previously failed tests. For example, if a test is a
compiled program that must be rerun by "make recheck", and its
compilation fails, it will still be rerun by further "make recheck"
invocations. See automake bug#11791.
* Bugs introduced by 1.12.1:
- Automake provides once again the '$(mkdir_p)' make variable and the
'@mkdir_p@' substitution (both as simple aliases for '$(MKDIR_P)'),
for better backward-compatibility.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New in 1.12.1:
* New supported languages:
- Support for Objective C++ has been added; it should work similarly to
the support for Objective C.
* Deprecated obsolescent features:
- Use of the long-deprecated two- and three-arguments invocation forms
of the AM_INIT_AUTOMAKE macro now elicits a warning in the 'obsolete'
category. Starting from some future major Automake release (likely
post-1.13), such usages will no longer be allowed.
- Support for the "Cygnus-style" trees (enabled by the 'cygnus' option) is
now deprecated (its use triggers a warning in the 'obsolete' category).
It will be removed in the next major Automake release (1.13).
- The long-obsolete (since 1.10) automake-provided $(mkdir_p) make
variable, @mkdir_p@ configure-time substitution and AM_PROG_MKDIR
m4 macro are deprecated, eliciting a warning in the 'obsolete'
category.