Thread: Target to make PS/PDF documentation?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Is there a target to make the tex (and from
there, the PS and PDF) versions of the gnuplot
manual?

I looked through the makefile, but found nothing
appropriate.

Best,

		Ph.

On Monday 01 September 2008, Philipp K. Janert wrote:
> 
> Is there a target to make the tex (and from
> there, the PS and PDF) versions of the gnuplot
> manual?

make pdf          # plain text pdf
make pdffigures   # pdf with embedded figures  (cvs version)

I wouldn't bother with a postscript version.

	Ethan

> I looked through the makefile, but found nothing
> appropriate.
> 
> Best,
> 
> 		Ph.
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

On Monday 01 September 2008 22:28, Ethan A Merritt wrote:
> On Monday 01 September 2008, Philipp K. Janert wrote:
> > Is there a target to make the tex (and from
> > there, the PS and PDF) versions of the gnuplot
> > manual?
>
> make pdf          # plain text pdf
> make pdffigures   # pdf with embedded figures  (cvs version)

In the doc/ directory! (Just found out. Does not seem 
to work from the gnuplot/ directory.)

Thanks. 

>
> I wouldn't bother with a postscript version.
>
> 	Ethan
>
> > I looked through the makefile, but found nothing
> > appropriate.
> >
> > Best,
> >
> > 		Ph.
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge Build the coolest Linux based applications with Moblin SDK &
> > win great prizes Grand prize is a trip for two to an Open Source event
> > anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

> > Is there a target to make the tex (and from
> > there, the PS and PDF) versions of the gnuplot
> > manual?
> 
> make pdf          # plain text pdf
> make pdffigures   # pdf with embedded figures  (cvs version)

I wish it is possible to list all useful make targets. For example I always 
use
	make install-strip
for installation, but it is undocumented.

Should this list go to the beginning of configured Makefile, or " make help" 
target, or to an INSTALL file?

---
PM

On Thursday 04 September 2008, Petr Mikulik wrote:
> > > Is there a target to make the tex (and from
> > > there, the PS and PDF) versions of the gnuplot
> > > manual?
> > 
> > make pdf          # plain text pdf
> > make pdffigures   # pdf with embedded figures  (cvs version)
> 
> I wish it is possible to list all useful make targets.

"useful" is tricky.
A simple-minded way to list all targets is
  grep : Makefile

or to reduce the noise a little bit
  grep '^[^ 	\.]*:' Makefile

As Phillip pointed out, however, not all of the subdirectory
targets are recognized from the top level directory.  I have
not really looked into that, but if someone has a quick fix
please let me know.

	Ethan

> For example I always  
> use
> 	make install-strip
> for installation, but it is undocumented.
> 
> Should this list go to the beginning of configured Makefile, or " make help" 
> target, or to an INSTALL file?
> 
> ---
> PM
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

FWIW

I'm not sure I understood the question, but this may be a 90% solution.  A little editing of the output is required, but it finds all the targets.  should be run in the top level directory.

Have Fun!
Reg

#!/bin/sh

find . -name Makefile -exec egrep '^.*:' {} \; \
| egrep -v '#|\$|.*=.*:|^ *\.'                 \
| sed 's/:.*/:/'                               \
| sort -u

Ethan A Merritt wrote:
> As Phillip pointed out, however, not all of the subdirectory
> targets are recognized from the top level directory.  

Ultimately the reason is that docs/Makefile.in is not made from a 
docs/Makefile.am, and that gnuplot.info is not our primary documentation 
source file.  If it were, it would only take a single line in 
docs/Makefile.am:

    info_TEXINFOS = gnuplot.info

and automake would automatically set up rules build the documentation in 
various formats.  The only downside, if any, would be that texinfo's 
"makeinfo" program would become a build prerequisite, since automake 
insists on building and installing at least the info version in such a case.

Oh, and FWIW, the options for building the other help document formats 
_are_ pointed at: right there in README it says:

<quote>The new gnuplot user should begin by reading the general information
available by typing `help` after running gnuplot. Then read about the
`plot` command (type `help plot`).  The manual for gnuplot (which is a
nicely formatted version of the on-line help information) can be
printed either with TeX, troff or nroff.  Look at the docs/Makefile
for the appropriate option.</quote>

And once you do look into docs/Makefile (or Makefile.in, if you haven't 
configured yet), it does mention ps, pdf and friends quite clearly.

On Thursday 04 September 2008 12:01:49 Hans-Bernhard Bröker wrote:
> Ethan A Merritt wrote:
> > As Phillip pointed out, however, not all of the subdirectory
> > targets are recognized from the top level directory.  
> 
> Ultimately the reason is that docs/Makefile.in is not made from a 
> docs/Makefile.am, 

I'm just trying to understand the mechanism.
"make pdf" does work from the top level directory,
but "make pdffigures" does not.  Why?
Some piece of the automake/autoconf process adds the necessary
dummy targets for pdf (and pdf-recursive) in all subdirectories.
But what triggers this?  
Is there some keyword I can add somewhere that will do the same for pdffigures?

	Ethan

> and that gnuplot.info is not our primary documentation  
> source file.  If it were, it would only take a single line in 
> docs/Makefile.am:
> 
>     info_TEXINFOS = gnuplot.info
> 
> and automake would automatically set up rules build the documentation in 
> various formats. The only downside, if any, would be that texinfo's  
> "makeinfo" program would become a build prerequisite, since automake 
> insists on building and installing at least the info version in such a case.
> 
> Oh, and FWIW, the options for building the other help document formats 
> _are_ pointed at: right there in README it says:
> 
> <quote>The new gnuplot user should begin by reading the general information
> available by typing `help` after running gnuplot. Then read about the
> `plot` command (type `help plot`).  The manual for gnuplot (which is a
> nicely formatted version of the on-line help information) can be
> printed either with TeX, troff or nroff.  Look at the docs/Makefile
> for the appropriate option.</quote>
> 
> And once you do look into docs/Makefile (or Makefile.in, if you haven't 
> configured yet), it does mention ps, pdf and friends quite clearly.
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Since we are talking about documentation,
here is something that has confused me 
before:

Apparently, the file
	gnuplot.texi
is under CVS version control. Shouldn't just
the master (ie gnuplot.doc) be in CVS, since
all other files are built from it?

Best,

		Ph.

On Thursday 04 September 2008 12:01, Hans-Bernhard Bröker wrote:
> Ethan A Merritt wrote:
> > As Phillip pointed out, however, not all of the subdirectory
> > targets are recognized from the top level directory.
>
> Ultimately the reason is that docs/Makefile.in is not made from a
> docs/Makefile.am, and that gnuplot.info is not our primary documentation
> source file.  If it were, it would only take a single line in
> docs/Makefile.am:
>
>     info_TEXINFOS = gnuplot.info
>
> and automake would automatically set up rules build the documentation in
> various formats.  The only downside, if any, would be that texinfo's
> "makeinfo" program would become a build prerequisite, since automake
> insists on building and installing at least the info version in such a
> case.
>
> Oh, and FWIW, the options for building the other help document formats
> _are_ pointed at: right there in README it says:
>
> <quote>The new gnuplot user should begin by reading the general information
> available by typing `help` after running gnuplot. Then read about the
> `plot` command (type `help plot`).  The manual for gnuplot (which is a
> nicely formatted version of the on-line help information) can be
> printed either with TeX, troff or nroff.  Look at the docs/Makefile
> for the appropriate option.</quote>
>
> And once you do look into docs/Makefile (or Makefile.in, if you haven't
> configured yet), it does mention ps, pdf and friends quite clearly.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Philipp K. Janert wrote:

> Apparently, the file
> 	gnuplot.texi
> is under CVS version control. Shouldn't just
> the master (ie gnuplot.doc) be in CVS, since
> all other files are built from it?

Should: yes.  The general rule is that files generated from others 
shouldn't go into version control themselves.  I.e. no Makefile.in, no 
Makefile, no configure, no gnuplot.info, and no gnuplot.texi.

But some people strongly objected to the idea that this would require 
everyone building from CVS to have Emacs...

The same objections keep us from installing a normal rule to rebuild 
gnuplot.texi automatically.  A CVS checkout jumbles timestamps, so even 
with gnuplot.texi in CVS, it would be rebuilt on most fresh checkouts.

Thanks!

On Friday 05 September 2008 12:04, you wrote:
> Philipp K. Janert wrote:
> > Apparently, the file
> > 	gnuplot.texi
> > is under CVS version control. Shouldn't just
> > the master (ie gnuplot.doc) be in CVS, since
> > all other files are built from it?
>
> Should: yes.  The general rule is that files generated from others
> shouldn't go into version control themselves.  I.e. no Makefile.in, no
> Makefile, no configure, no gnuplot.info, and no gnuplot.texi.
>
> But some people strongly objected to the idea that this would require
> everyone building from CVS to have Emacs...
>
> The same objections keep us from installing a normal rule to rebuild
> gnuplot.texi automatically.  A CVS checkout jumbles timestamps, so even
> with gnuplot.texi in CVS, it would be rebuilt on most fresh checkouts.

Thread: Target to make PS/PDF documentation?

A portable, multi-platform, command-line driven graphing utility

gnuplot-beta