Re: Making demo programs more evident...

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Sun, 9 May 2004, Petr Mikulik wrote:
>  
>
>>=> ordinary people (who do just "make install" have no demos avaible).
>>    
>>
>
>  
>
>>INSTALL writes ./configure does not want to decide where to put demos --
>>why not?
>>    
>>
>
>INSTALL says so, and it's written in there for said "ordinary people" to
>see.  So they'll know there are demos they may want to install, at a place
>of their choosing.  
>
>We can't do anything to help people who won't read README and INSTALL
>files, and there's really no point trying.
>
>>/usr/local/share/gnuplot/... gnuplot is already writing there, why not use
>>it for demo?
>>    
>>
>
>That would be the right place for them to go for a non-RPM local
>installation from sources.  I.e. if we make a "install-demos" target, or
>have the default 'install' put them up anywhere, $(pkgdatadir)/demo is 
>where that'll be.  
>
>But it's not the place the existing binary packages made by third parties
>put them.  SuSE Linux, e.g., puts such files below
>/usr/share/docs/packages/<name>, not /usr/share/<package>, and they may
>prefer to keep it that way.  But since there's no
>/usr/local/share/docs/packages in a Linux system, we can't easily
>duplicate that, and probably we shouldn't.
>
>And remember that as soon as we put a pointer to the locally installed
>copy of the demos into the online help, odds are distributors will manage
>to break it.  But it'll likely be us who get the complaints about it.
>

I was going to say that the distributor/packager or whatever can move 
them to where ever they want.  But point taken.

I think the additional method requiring installing demos isn't so bad. 
 That is, a separate "make install-demos" which would require some 
interaction (i.e., specifying the exact directory, the "make 
install-demos" would automagically define GNUPLOT_LIB and add the demo 
directory to it) would be something only run by the distributors.  The, 
eh-hem, "non informed people" could then still type "make, make install" 
and hope for the best, i.e., watch the pretty glowing characters wiz by. 
 Then at the very end of the "make install" after the message indicating 
everything is hunky-dory, there could be a message noting the existence 
of demo scripts that can be installed.

Well, in any case, if a message in the INSTALL file were to do, perhaps 
add a GNUPLOT_LIB comment.

   The gnuplot demo files are not installed by default, mainly because
there is no universally agreed place where such files should go.
If desired, they should be copied manually to a location of choice.
(add this) Including the chosen demo directory in the global variable path
GNUPLOT_LIB (see below) will allow easy access for all users
to the demo script files.


>>BTW, "make install" installs big unstriped binaries, even for the final
>>gnuplot 4.0.0. It's not polite for harddisks of our users. I hope no other
>>app do that!
>>	Who knows about "make install-strip", and who actually use it?
>>    
>>
>
>Those people who care, know.  Those who build RPMs at distributors
>included.  OTOH, HD space is less than 0.01 USD or EUR per MB these
>days...
>

Well, that kind of thinking only promotes sloppy computer usage... like 
putting an extraneously high resolution image on a web site.  I will use 
"install-strip" from now on if I remember.

>It might make sense to mention install-strip in the INSTALL document.
>

I assume that non-stripped is the default because developers want to do 
debugging?  And they don't want to have to be constantly typing the 
"make install-debug" or something similar.  How about a global variable 
for controlling this?  That is,

install-stripped:  same as current "install-stripped" behavior
install-debug:  same as current "install" behavior
install:  Include debugging information according to a global variable 
GNUPLOT_DEBUG; i.e., defined then include debug info, if not (default) 
then don't include debug info.  For developers, define GNUPLOT_DEBUG 
once and that is it.

Dan