Re: debmake: a compromise?
On Thu, 20 Feb 1997, Richard G. Roberto wrote:
> I would personally like to see debstd help to generate a rules
> file that could later be tweaked the same way debmake creates
> various templates to be tweaked. Adding verbose options to
> debstd would be good as well. I'd particularly like to see it
> have the ability to tell you why its doing what its doing.
> Something like the output from some "configure" scripts.
That is a feature wanted. I would be glad if someone wrote a compiler like
that but I certainly have not enough time to take care of it. I barely had
time developing debmake using shell scripts...
>
> For example:
>
> debstd: checking for documentation ...
> debstd: found foo.1, README, COPYRIGHT
> debstd: compressing documentation with gzip -9 ...
> debstd: creating directory structure under debian/tmp ...
> debstd: installing man page "foo.1" into debian/tmp/usr/man/man1
> debstd: checking for binaries ...
debmake already does list the manpages. README COPYRIGHT are explicitly to
be specified by the maintainer anyways. Directories are created according
to the maintainer specified contents of the "dirs" file.
> This is probably not a real good example, but you get the idea.
I am sorry I still do not get the point.
> By the way, debstd is not a _simple_ bourne shell script and isn't
> all that easy to read. It is at first, but then there are a
> couple of functions that are larger than most bourne shell
> scripts, and finally the main program. I think the average sh
> script writer would have problems reading the code and figuring
> out what's happening when (I did). For example, there are if
> clauses that go in and out of 6 and 7 levels deep, into and out
> of case blocks, etc., all in the same funtion. Tracing the
> execution of debstd by reading the script is unappealing (unlike
> many other aspects of debmake, which are very appealing).
The clauses are all clearly indented and very easy to follow. I have had a
number of people reviewing debstd and offering improvements /patches.
> The fact that we're discussing all of this after the utility has
> been written instead of discussing before writing it is what Ian
> is objecting to. I'm reluctant to make such objections as I'm
> not really qualified to. In the public domain, the "law of the
> land" is usually "put up or shut up". People don't usually go
> throuth the process of clearly defining a design spec and
> implementation plan until they have at least 5000 lines of code
> ;-)
Debmake has been written with constant interaction with other project
members and interaction on debian-devel. debmake is cleanly designed and
the design has been completely reworked a couple of times in order not to
have spaghetti code.
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
Please always CC me when replying to posts on mailing lists.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: