Re: [Gnu-arch-users] Managing changes to projects that use autoco nf/automake with tla

[Tom Lord]

    > From: "Parker, Ron" <address@hidden>

    > By the way, having worked a little bit with package-framework, I
    > like it.

Thank you.  I think it illustrates the right abstractions well, but as
a practical matter, should be implemented in a completely different
way.  On certain dark days, I think it's worth the trouble of writing
tiny but much cleaner implementations of sh and mk and a little
scripting language -- highly portably -- small enough to reasonably be
included with most projects.


    > In some respects it is much simpler than auto*, of course it also lacks 
some
    > of the features, but those can easily be added as needed.  For example, I
    > tweaked my local build-tools/Makefiles/programs.mk to allow prefixing an
    > executable file name.  It wasn't something I absolutely had to do, but IMO
    > it was better than editing that project's Makefile.in rules to do the
    > prefixing in all the various rules.  Plus it was a good exercise in 
testing
    > package-framework's extensibility.  I wouldn't want to try to add that to
    > auto*, if it didn't already exist.  "Your trapped in a twisty series of m4
    > p4ss4ages, all alike.... A giant Perl attacks you from the darkness.... 
You
    > have died.... Reloading...".  Yuck.

Auto* failed.

They were born to ensure reliably portable and precise build processes
and help people write very portable code.  They did so for the first
few years.  Lately, they have evolved to become tools for making very
twisted GNU/Linux-specific build processes and ugly code that isn't
quite portable after all.


    >> The next idea is to not generate those files in the source tree ---
    >> always use a separate build tree.

    > I build in src/=build, but it still modifies the files in the source
    > directory due to the way automake works, creating Makefile rules that 
update
    > the "source" Makefile.in, etc. to match one's version of automake.

Sigh.

-t