Friends -
The CVS pcb I'm playing with can't build from read-only sources.
Let me explain.
Everyone is used to
tar -xvzf package.tar.gz
cd package
sh autogen.sh
./configure
make
Where the autogen.sh step is not normally needed, but I include
it here because my package.tar.gz is really just a CVS snapshot.
A related process, that is supported by configure and based on
the VPATH make feature, is
tar -xvzf package.tar.gz
(cd package && sh autogen.sh)
mkdir package-bin
cd package-bin
../package/configure
make
This keeps source and binary separate. And again, if this were
a real pre-autogen'd snapshot, you could drop the "cd package &&
sh autogen.sh" step. Now let's actually enforce the separation:
tar -xvzf package.tar.gz
(cd package && sh autogen.sh)
chmod -R a-w package
mkdir package-bin
cd package-bin
./configure
make
Bang! The pcb build trips up badly in the doc directory.
The first (but not the only) problem is with this gem of
a Makefile rule:
$(srcdir)/stamp-vti: pcb.texi $(top_srcdir)/configure
@(dir=.; test -f ./pcb.texi || dir=$(srcdir); \
set `$(SHELL) $(srcdir)/mdate-sh $$dir/pcb.texi`; \
echo "@set UPDATED $$1 $$2 $$3"; \
echo "@set UPDATED-MONTH $$2 $$3"; \
echo "@set EDITION $(VERSION)"; \
echo "@set VERSION $(VERSION)") > vti.tmp
@cmp -s vti.tmp $(srcdir)/version.texi \
|| (echo "Updating $(srcdir)/version.texi"; \
cp vti.tmp $(srcdir)/version.texi)
[EMAIL PROTECTED] -f vti.tmp
@cp $(srcdir)/version.texi $@
Obviously, having $(srcdir)/stamp-vti as a target doesn't fit
the above build strategy. I'm not sure if the fault is with
the pcb Makefile.am, or (more likely, given the template I find
in /usr/share/automake-1.9/am/texi-vers.am) autoconf-1.9.
But it resisted my efforts to bypass the problems.
Note that while changing permissions may seem artificial, it
is a simple stand-in for other cases where the source tree is
intrinsically immutable -- it could be owned by a different
user, it could reside on CD-ROM, or on an anonymous (and
therefore read-only) NFS mount. Other motivations come from
cross-builds, where you would like a common source tree, and
independent builds for multiple targets.
The only other Free Software package in which I ran into problems
this way was glibc, many years ago. All sorts of other software
"just works".
I think this list includes people with deeper understanding
of the whole autoconf/automake/configure flow. Any ideas?
- Larry
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
