Hi,
On Thu, Feb 04, 1999 at 07:17:10PM -0600, Gilles Detillieux wrote:
GD> > Some changes with respect to install.. I prefer installing the html stuff
GD> > and the cgi to a /home/httpd/htdig/ directory.. (which is then again a
GD> > virtual root for apache).
GD>
GD> Hmmm. That requires a customised setup of Apache for it to work.
GD> I had set up my RPMs so you could drop them onto a standard Red Hat
GD> installation, with their uncustomized Apache RPM, run rundig, and you're
GD> off. That's why I used the paths that I did. I guess this is one of
GD> those situations that Geoff alluded to about "support for everyone's
GD> favorite packaging scheme."
My rationale behind it is that nothing starts running on a system without
it being put there knowingly. Another matter is that if you use it in a
running environment you might put something in your webservers root without
wanting it. Suppose I have a a customized search.html in my webroot. Then
it gets moved my rpm to a .rpmorig... and another one would be brought
online... For a unknowing user that might be something of a suprise. In the
end it's a matter of taste, I completely agree.
> Anyway, it doesn't matter to me which spec
GD> file winds up in contrib, mine or yours.
I didn't change much it's still yours as far as I'm concerned ;)
GD> Your patch to CONFIG.in is just the thing to take all the paths out of
GD> the source and put them all on the configure command line in the spec
GD> file. I wonder, though, whether other users will want those changes
GD> as a permanent part of CONFIG.in in the source tree. If so, great,
GD> because then the RPMs won't need to include any patches, but if not,
GD> then this one patch will still have to remain in the RPMs.
I have a big preference for patch-less configuration. configure scripts are
IMHO meant to configure. I was at first kindoff surprised that the
configure scripts --bindir option did not work as I thought it was supposed
to do. Hey even your spec file gave the impression you supposed it should
work ;) ;)
GD> I used your patch to the Makefile.in files, but then I made a few more
GD> changes to clean things up, and echo the actual locations where files
GD> are installed. I also put the HTML & dictionary file installations in
GD> loops, to make things tidier. Here's my patch to your patched Makefile.in:
Is indeed a lot tidier. One thing I didn't do with the CONFIG.in it's a
good idea to derive the IMAGE_URL_PREFIX from the IMAGE_DIR var or vice
versa. Because if you change the IMAGE_DIR now you still have to patch the
IMAGE_URL_PREFIX. In my initial setup I had a htdig/cgi-bin and a
htdig/images dir in the webserver directory. But I wanted it finished so I
didn't bother.
GD> > - vars.Add("PLURAL_MATCHES", new String(nMatches == 0 ? "" : "s"));
GD> > + vars.Add("PLURAL_MATCHES", new String(nMatches == 0 ? (char *)"" : (char
*)"s"));
GD> 1) it seems harmless enough, so if it helps with egcs, then great! It's
GD> quite odd, though, that egcs would need those type casts. I thought any
GD> character string in double quotes was a char *, in C and C++. Why does
GD> egcs seem to think otherwise?
In C++ it's a (const char *). Egcs (mabye newer gcc's too) marks these as
'meat' for a read only segments. Solaris honores this. (I don't know for
sure if Linux does this too?). Now you might see a reason for a lot of
potential segfaults in the future.
In this case the cast to a (char *) works. But as with any cast you should
know what you are doing... This cast may be a segfault in a future version
due to changes in the string classes. The real clean way is to make a const
constructor. But that's a lot of work, at least with 3.1.0b4, the later
snapshots made less of a problem of this and the things that would segfault
due to this seem to have dropped out.. I didn't look much at the changes in
the String classes in this snapshot and the why's. I was a bit fixed on
getting the thing RPM-ed and running again.
Hmmmm I guess, I owe you ppl also an apology for not noting this in the
patch with a comment. :( As I said I was a bit fixed on getting it running
again. There's a good chance we might start using htdig here at the
Telematics Institute, so far the $5000 and up competition offers not much
extra functionality for their money. And I'm certain they can't give bug
fixing speed of a open source project. (I guess I'm saying that you people
are doing a great job =) )
Cheers,
Ric
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
