Re: Possible framework for `debmake replacement'

[Ben Pfaff <pfaffben@pilot.msu.edu>]

>It seems to me that we have a problem here which is somewhat similar
>to that tackled by autoconf: we want to generate a script (in this
>case a makefile, the debian/rules) and assorted other stuff in a
>fairly automatic template-based manner from a simpler file which gives
>the specifications of things.
>
>Perhaps we could have debian/rules.in or debian/spec or something be
>an M4 script which is processed either once or several times to
>produce the debian/rules, postinst/preinst, &c.
>
>This is just an idea, but I'm mentioning it because it seems to me
>that using M4 would avoid you having to write a separate parser for
>the specification file, and might make it easier to add the kind of
>hooks you might want.

[Warning: overly verbose content below.]

I started writing something like this a few days ago, using an
`autoconf' model.  But there's one problem that I haven't come up with
a good solution for.  I'll try to explain it clearly.

Firstly, debmake is a `runtime' type tool.  It runs the debstd script
inside of the `rules' makefile.  This means that it can detect where
everything has been installed (i.e., manpages, info files, etc.;
perhaps these aren't good examples but you get the idea, right?).  So
these sorts of things don't have to be manually specified.

However, there's no way for a `autoconf'-type tool to know where these
things go automatically, unless it can somehow guess them from reading
the source Makefile.  I've come up with two possible solutions:

	1. Force the user of the tool (`Debelope' by name) to specify
exactly what is being installed.  This seems to defeat the purpose of
the package because it doesn't make anything easier.

	2. Divide the packaging process into two passes.  In the first
pass, an initial rules file is built, with a call to to a
`debstd'-like program, with the difference that instead of actually
doing what debstd does, it emits a list of bash commands that do what
debstd would have done.  In other words, instead of being an
`interpreter' like debstd is, it's a compiler.  (Somehow else tried to
make this distinction earlier, but it got misinterpreted.)

	Example of this second idea:

	Suppose the package provides static libraries, like a *-deb
package.  First Debelope generates an initial `rules' files that runs
a `debstd' derivative, and it executes `rules binary'.  `debstd' would
normally handle static libraries by `strip'ping them.  However, this
derivative program handles them by outputting the `strip' command to a
temporary file.  After the `rules' finishes running, Debelope takes
the contents of this temporary file and generates a final `rules' file
with the `strip' command substituted into the `binary' target.
-- 
Ben Pfaff <pfaffben@pilot.msu.edu> 12167 Airport Rd, DeWitt MI 48820, USA
PGP public key and home page at http://www.msu.edu/user/pfaffben


--
This message was delayed because the list mail delivery agent was down.