Replies to multiple...
On Thu, 2007 Mar 08 09:46:48 +0000, Philip Hazel wrote:
>
> > What if the Subversion repository were to have a pre-commit script that
> > would check the files being committed for trailing whitespace, and reject
> > the commit if present?
>
> That is another possibility. I'd have to check whether any of the test
> data files (which I do not detrail) have any significant trailing
> whitespace
If anything, the script can be written to exclude certain files from the
whitespace check. (Though of course it would be better to apply the rule
unconditionally.)
> > I think that the scripts to generate the HTML files from the man pages
> > should be a part of the distribution, so that the HTML can be updated
> > without pulling stuff from SVN. We can define the HTML files to be
> > "maintainer-generated", so that "make clean" won't delete them (you would
> > have to do "make maintainer-clean"), yet the rules to generate them can be
> > fully integrated with Automake.
>
> OK, but the current Perl script that generates HTML is a local one that
> I wrote; it knows about the format in which I write man pages, but it is
> not a general "man-to-html" script. It's a while since I did it, and I'd
> have to look to check, but I think there is some magic so that it gets
> various cross-references right and turns them into HTML links.
There's no problem with that---ideally, there would be a bit of
documentation so that someone editing the man pages will know what is going
on, but otherwise this poses no issue. Normal users would not be running it
in the course of a standard build, after all.
> This raises the more general question of what the distribution actually
> is. I've always thought of it as a distribution for users, not for
> maintainers, but it seems as though you and others think differently.
Very true. The common practice is to have a tarball loosely partitioned
into "maintainer-built files" and "user-built files," where the former may
require special tools to build (e.g. Yacc parsers) and are bundled in the
tarball; where the latter is usually just binaries/libraries and other
files that cannot be built "in advance" for the user.
This is what the --enable-maintainer-mode option in many Autotoolized
packages gets at, incidentally.
> I put stuff into a maintain/ directory that I thought shouldn't be
> distributed because is is for maintainers only; if we start to
> distribute some of this, should it come out of that directory?
It could stay there (this is a subdirectory below pcre/, yes?), depending
on how the final directory structure should look like---the actual location
in the package isn't particularly important, given that the makefile(s)
would refer to it regardless.
(I would rename it to "maint", however... more precedent for that :-)
> > "config.h" should not be present as a file in the tarball. I would call the
> > file e.g. "config.h.manual", with the expectation that it would be renamed
> > if needed.
>
> By that argument, we should then also rename pcre.h as pcre.h.manual in
> the tarball. What is the consensus on this? Please let's get it settled
> so that I don't have to keep on editing README and NON-UNIX-USE.
pcre.h is somewhat of a special case, since all it has as far as variable
bits go is the version number. You could think of the pcre.h.* -> pcre.h
conversion as merely "updating" the pcre.h file.
I'd keep pcre.h.in/pcre.h as is. As for config.h.manual... one other thing
to consider is that, in the Autotools canon, config.h.in is really supposed
to serve that purpose. That's why we go to the trouble of putting nice
comments into it. Are you imagining a "config.h for by-hand builders" that
is significantly better than config.h.in?
On Thu, 2007 Mar 08 10:08:41 +0000, Philip Hazel wrote:
> On Thu, 8 Mar 2007, Daniel Richard G. wrote:
>
> > Philip, what sort of build environments are we talking about where
> > ./configure (or CMake) isn't an option, again?
>
> I don't know in detail - people have emailed me from time to time about
> the weird and wonderful special-purpose environments they use, but I
> haven't kept records. I may be imagining it but perhaps one was an OS
> used on cell phones. That kind of thing. I myself still have an old
> Acorn computer at home - no longer used, but years ago I did put PCRE on
> it "by hand", and there are still people using those systems.
Interesting :) Could you say if a Make program was a common thread between
most of these systems? I wonder if e.g. AcornOS is like Windows in this
respect (which has NMAKE but no POSIX to speak of).
> Does OpenVMS have configure/make? I remember somebody put PCRE on that.
> How about mainframe OS? They didn't have configure/make in my day, but
> that's about 15 years ago now.
I've seen tarballs that bundle Makefile.vms, so I would assume that the
usual POSIX toolset can't be counted on there either.
You know, I'm not so sure that these little "shortcuts" we've been
discussing, to facilitate non-Autotools/non-CMake builds, are ultimately
worth the effort. The user would still have to assemble (by hand) the moral
equivalent of a makefile, and the favors we're doing him/her are trifles in
comparison.
On Thu, 2007 Mar 08 09:53:52 +0000, Philip Hazel wrote:
> >
> > But I don't have strong feelings. If you guys want to leave stuff out
> > of that dir, fine by me.
>
> I don't want to leave anything out of the doc directory. I just don't
> want to install some of them into /usr/local/share/doc/pcre/ (or
> wherever).
Yes, there seems to have been some confusion w.r.t. {in,ex}cluding files
in/from the tarball, vs. installing them or not on "make install".
Very few files would be excluded from the tarball. autogen.sh is a typical
example, although even there, some projects will throw it in.
--Daniel
--
NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef?
EMAIL1 = skunk@??? ## don't smell bad--- (/o|o\) /
EMAIL2 = skunk@??? ## it's the people who < (^),>
WWW = http://www.******.org/ ## annoy them that do! / \
--
(****** = site not yet online)
