bug#8362: make install prefix inserted in source code with generated python files
On 21 Mar 2023 23:05, Bogdan wrote: > Third, and most important (I think) is that we need to note that > "prog/x.py" is GENERATED, but is NOT marked so. Adding > > BUILT_SOURCES = prog/x.py i don't think this is a correct use of BUILT_SOURCES. https://www.gnu.org/software/automake/manual/automake.html#Sources that var is meant for generating headers before Automake's depgen logic can kick in. that sounds minor, but in practice it means that every built source is generated before anything else is compiled. which can insert a bubble into parallel build pipelines. so we would prefer it only be used for things that matter to header dependency generation. -mike signature.asc Description: PGP signature
bug#54020: Allow user-defined libtool options
On 15 Mar 2023 17:31, Bogdan wrote: > Another patch from my side. This one makes it possible for users to > pass additional options to libtool in 'compile' mode. Fixes #54020. > > Added documentation and a test case including the '-no-suppress' > option. All tests with 'lt' or 'libtool' in the name pass. > > Feel free to rename the variables, I just came up with the names > LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS, reflecting the positions > where the variables are put and the mode they're used in. why do we need LTCOMPILE_POSTFLAGS ? isn't that just after the compile command ? $obj_compile expands into e.g. \$(CC) @cpplike_flags \$(AM_CFLAGS) \$(CFLAGS) so if someone wants to add flags to C/etc..., they already have knobs to turn. which means this would simplify by only having one variable right ? AM_LTCOMPILE_FLAGS -mike signature.asc Description: PGP signature
bug#62069: Support xz parallel compression in dist-xz
On 09 Mar 2023 08:47, Sam James wrote: > xz supports parallel compression which obviously speeds up > the time taken to run the 'dist-xz' rule, but it also > speeds up *decompression* too, as the parallel compressor > creates different output which can be decompressed in parallel. > > There's two options, I think, for automake: > 1. Pass -T+1 to xz if xz is >= 5.4.0 (a runtime check > would be needed, but it's cheap to do) as this uses > 1 thread, but uses the parallel compressor to do it, > so allows decompression in parallel by users; > > 2. Pass -T0 (or -Tn, n >= 1) to allow autodetection > of the number of available CPU cores (or n if specified) > which also then naturally uses the threaded compressor. it should be a configure check when dist-xz is enabled in the call to AM_INIT_AUTOMAKE, and we should default to `-T0`. this would be the default XZ_OPT value if it hasn't been set/overridden (where we use -e now). -mike signature.asc Description: PGP signature
bug#68274: automake 1.16j nonnumerical version confuses scripts
On 06 Jan 2024 15:37, Karl Berry wrote: > Automake and other packages have used letters for pretests for decades, true ... > and it's not plausible to change now. eh ? there is nothing requiring or restricting the current version behavior other than "it's always been this way". but that doesn't mean it's better. there's no reason we couldn't use more modern convention here like -rc#. appending a letter at the end to indicate a *pre*release is extremely uncommon nowadays. > Also, I have the impression that other packages use random git hexids in > their pretest releases, which aren't numeric either. -k some do, but they use separators which makes it easier to split+compare. if they smashed it together, it'd be impossible to determine where the version stopped and where the git sha started. e.g. 1.2.3-gab989de -mike signature.asc Description: PGP signature
