On Wed, 2007 Mar 07 15:59:19 -0800, Craig Silverstein wrote:
>
> I'd say anything that's simple enough to put into the actual
> distribution without too much trouble, should do so. The idea is that
> if people download the distribution and make local changes, it would
> be nice to make it as easy as possible for them to do that properly.
> So if I download pcre and want to change the docs to add some
> site-specific info, it would be nice if make could update the html
> docs for me automatically.
Agree 100% there.
> For things like making the ucptable, where the input isn't part of the
> distribution, it makes less sense to include it in the distribution
> directly.
True, though it wouldn't hurt to bundle the script that would be used (even
if other data files need to be obtained as well to use it).
> Then again, my bias is to always give the person downloading the
> .tar.gz, as much info as possible. That's why I stuck every text file
> you could think of into the doc directory. I figure it can't hurt,
> and may well help.
Keep in mind the distinction between (1) rolling a file (or not) into the
dist tarball, and (2) copying the file out (or not) on "make install". I
believe Philip was concerned with #2; #1 is being done as a matter of
course.
> } [*] A new preparatory thing has been suggested by someone who builds
> } PCRE by hand (i.e. without the Autotools). I have already arranged
> } that config.h is included in the distribution to help with this
> } case. The suggestion is that every #define in config.h should be
> } wrapped with #ifndef/#endif so that he can use -D on the compiler
> } command line to override without having to edit config.h. This can
> } easily be done as part of the PrepareRelease script.
>
> Enh, I'm not a big fan. The lcilent should either use config.h, in
> which case they can edit it to their heart's content, or they should
> not use config.h, in which case they can just specify everything they
> care about on the commandline. This mixing-and-matching is, I think,
> asking for trouble.
That's what I'm thinking too... config.h and -Dfoo=bar are meant to be
orthogonal approaches. Are there compelling use cases otherwise?
> I disagree with the other comment, btw, that we should rename config.h
> to config.h.manual. I'd like it if things had a chance of Just
> Working out of the box, even for people who can't run ./configure.
Problems with this:
1. If the user runs ./configure, the file gets blown away
2. It confuses the issue for out-of-source-tree builds (do we use
$(srcdir)/config.h, or $(builddir)/config.h?)
3. It's poor form to distribute what is technically a system-specific file
4. There is precedent for distributing hand-tuned config.h files under
suffixed names (e.g. config.h.win32, config.h.vms)
> That suggests, I think, that the default config.h we put in the
> distro, in addition to being really well commented, should have
> reasonable defaults for, say, a windows system. :-)
Point #3 above.
Philip, what sort of build environments are we talking about where
./configure (or CMake) isn't an option, again?
--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)
