We are developing an application using a framework. Both the application and the framework are maintained using Subversion. The Subversion repository for the application defines a Subversion "external" for the framework: http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
This saves us from duplicating the framework in the application
repository, and having to merge changes to the framework into our
application repository. However the framework is distributed in our
application tarballs, produced by `make dist`
Unfortunately, we had to make some local changes to the framework,
specifically for our application. For the time being, it is still easier
to maintain the application and framework in separate repositories, and
maintain our application specific framework changes in patch files in
our application repository.
I created a "patch" rule in our application Makefile.am for applying
these patches:
patch: patch-stamp
patch-stamp: patches/*
cat patches/* | patch -p0
touch $@
This rule works OK: The first time `make patch` is called, it applies
all our local patches. As long as the patches have not changed,
subsequent calls to `make patch` result in "Nothing to be done". When
patches are changed, user intervention is required to revert changes to
the working copy of the framework before applying our updated patches.
Now, the framework distributed in our application tarballs should have
these patches already applied, so I tried getting the automake "dist"
rule to depend on our "patch" rule, without success. There does not
appear to be a "dist-local" rule, and the "dist-hook" rule is run after
files are copied to the distdir: By making "dist-hook" depend on
"patch", our patches are applied after files are copied to the distdir,
so the files in the tarball do not reflect our changes.
Any suggestions how to ensure automake's "dist" rule generates a tarball
with our patches applied?
Thanks and best wishes, Jack
signature.asc
Description: This is a digitally signed message part
