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

[Hans-Peter Diettrich]

Marco van de Voort schrieb:
> 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?

Tell me a reason why it does *not* deserve documentation.

> If you think it should, please annotate such things in the wiki.  :-)

What do you expect me to annotate? That I'm missing a documentation of 
the options, which the user can add on a "make" commandline?


>>> (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.

They become part of the project created using --write-project. This is 
not noticeable in the RTL and FCL projects, where all files reside in 
the same directory. When e.g. the LCL refers to the RTL and FCL, the 
content files (--import) reside in different directories, so that at 
least macros or environment options have to be used to evaluate the 
pathes on a user machine.

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


>> 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.

This part was in response to the generation of local documentation by 
the new installer (FPCup) of Reinier.


>> 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.

See this snippet from your posted make:

 >>
make[1]: Entering directory `D:/repo/fpcdocs'
../fpc/utils/fpdoc/fpdoc  --warn-no-node --package=rtl --descr=rtl.xml
--content=rtl.xct --hide-protected --descr=system.xml --input="-dfpdocsystem
-- -dHASGETHEAP
STATUS -dSUPPORT_DOUBLE ../fpc/rtl/win32/system.pp -Fi../fpc/rtl/win32
-Fi../fpc/rtl/unix -Fi../fpc/rtl/inc -Fi../fpc/rtl/i386 -dCPU32 -dHASVARIANT
- -dFPC_HAS_TY
PE_EXTENDED -dHASWIDECHAR -Fi../fpc/rtl/win -Fi../fpc/rtl/win32
-Fi../fpc/rtl/unix -Fi../fpc/rtl/linux" --descr=objpas.xml
<<

I'd suspect that "-Fi../fpc/rtl/win32" together with 
"-Fi../fpc/rtl/unix" can result in problems. At least the results depend 
on the search order for the include files.

An older MakeFile even added pathes twice, and this has been fixed.


>> 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.

This is not only a make problem, it also turned out that FPDoc, 
build_lcl_docs, and maybe even RTL functions, have problems with mixed 
directory separators. Problems can arise when a script uses the current 
platform separators, and these are different from the separators stored 
in an fpdoc project file.

DoDi