[Lazarus] Lazarus trunk help options: CHM Help browser does not show up

[Marco van de Voort]

On Fri, Feb 17, 2012 at 08:05:51PM +0100, Hans-Peter Diettrich wrote:
> > In theory
> > 
> > make chm DOCS="rtl fcl" should do it, but it currently hits windows
> > commandline limits. (see below to get an idea)
> 
> Where is the DOCS option (and more) documented?

Should it be? 

If you think it should, please annotate such things in the wiki.  :-)
 
> > Dodi is right that the
> > bulk of the definition of filenames and paths should move out of the
> > makefile and into a project file. Michael is working on this, but still
> > WIP.
> 
> The problem was not the length of the commandline.

> The AVs are/were due to duplicate include paths or defines, created from
> the MakeFile.  This should have been fixed in FPDoc already.

I haven't said anything about AVs. See the makefile I posted.

Afaik I once tried to run the commandline constructed on linux on Windows 
via tprocess. That worked fine. Probably because it avoids shell and
make limitations.

> > (IMHO this should not be needed. A system that relies on random hardcoded
> > paths in a particular setup is flawed)
> 
> References to the content files of required packages require 
> installation-specific pathes. 

Then they shouldn't be in the project system, but passed on the commandline,
or a seperate settings file.

Having to edit project files before using them, just switches one voodoo
solution by the other.

> The installer should know, however, in 
> which directories the files reside, and can create the commandlines 
> accordingly.

Which installer? Primarily docs are run by release engineers from svn. 
This use should be central.
 
> Another problem is the OStarget, which is somewhat hard-coded in the 
> MakeFile, and then mixed with the current platform in the MakeFile.

That is a totally different problem. A quality solution for that is very
costly, and IMHO that time can be spent on better things. 

> FPDoc adds further defines to the input specs, to increase the confusion 
> and chance for errors. The input specifiers in a project include the 
> settings derived on the machine on which the project was created, which 
> will mix up with the settings added by FPDoc at runtime. One such 
> problem has already been fixed in the MakeFile.

I've no idea what so ever you are talking about.
 
> And one more problem are inconsistent directory separators. At least I 
> had to fix several paths already, before passing them to fpdoc or makeskel.

That is general crossplatform and make problems. One of the reasons for me
that make has to go long term.

New versions of half of the win32 tools we use aren't available, and the
newest are from 2005.

> > ----------------------
> > 
> > 
> > D:\repo\fpcdocs>make CHM DOCS="rtl fcl"
> > make html HTMLFMT=chm
> > make[1]: Entering directory `D:/repo/fpcdocs'
> [...]
> This looks like an apostrophe (single quoted) added to the path?

> cause error messages on Windows, like reported here:
> > '..' is not recognized as an internal or external command,
> > operable program or batch file.
> > make[1]: *** [rtl.chk] Error 1
> > make[1]: Leaving directory `D:/repo/fpcdocs'
> > make: *** [CHM] Error 2
> 
> These bugs should have been fixed in the MakeFile already.

Newest checkout. Up to date snapshot.