On Sat, Oct 25, 2003 at 10:10:03PM +1000, Zenaan Harkness wrote:
> build, depends on build-stamp
>
> build-stamp, yes (may be this is what you meant by configure-stamp?),
> depends on config.status
This is correct. That means that when config.status becomes newer than
build-stamp, build-stamp must be regenerated and hence the steps taken
to create it will be re-run (new configuration variables from
config.status.)
> config.status, depends configure
Ok. You may depend on a specific file without having an actual target
for it. Basically, when config.status becomes older than configure, it
should be run again.
What happens when you do debian/rules config.status?
Is there a config.status already in the package? It might have the same
timestamp as configure. This would be an error.
> Here is the relevant portion of rules, mostly auto-generated by dh_make:
>
> =====
> config.status: configure
> dh_testdir
> # Add here commands to configure the package.
> CFLAGS=$(CFLAGS) ./configure --host=$(DEB_HOST_GNU_TYPE) \
> --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr \
> --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
It looks okay to me. But maybe your configure script isn't an autoconf
script, because only autoconf configure scripts produce config.status.
> > You want to stick ./configure into the configure-stamp target, then
> > touch configure-stamp.
>
> If you need, I can post the whole file, but as mentioned there's no
> configure-stamp, dependency or target.
Maybe that could help. What about just the whole Debian source you're
working with? Then maybe we could get cooking.
--
Joshua Kwan
Attachment:
pgpWfBlTKzMcB.pgp
Description: PGP signature