I do a complete fresh installation of Lazarus
(lazarus-1.2.6-fpc-2.6.4-win32.exe) from 20.1.2015, on a complete fresh PC. I found the chm documentation in the Lazarusinstalldir/docs/chm, but the files in this directory are from 24.8.2012 13:21 !!

Is this the last documentation and correct for this build ?

In the readmechm.txt file i found following
--------------------- citation start ---------------- This CHM snapshot was build on 2012-08-01 by using fpdoc from trunk to compile the docs for fixes2_6 and the lazarusrc1 tag.

How to install the CHMs in Lazarus
------------------------------------

- Install the chmhelp package
- Copy the chms to docs/html in the Lazarus directory.

Note that Lazarus does not load ref.* at this moment, so (CHM) help on keywords does not work yet.

--------------------- citation end ----------------

The chm are in the rigth place, i think, why should i transfer the files to the docs/html directory ? Maybe the information in the file is also outdated.

Andreas

perhaps that is the solution?

http://sourceforge.net/projects/lazarus/files/Lazarus%20Documentation/Lazarus%201.2/

Maybe, a solution, but the files inside the download have the date 19.06.2013 11:06. This more than one and a half year old ! For the fpc it can be ok, but for Lazarus, i don't know.

Andreas

Shouldn't the CHM files be (re)generated when a full build is made?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150120/b9a4d624/attachment.html>

Kostas Michalopoulos wrote

Shouldn't the CHM files be (re)generated when a full build is made?

FPC chm's are generated on every RC and final build. Last is for 2.6.4 and can be found in the doc dir of FPC, dated 2014-02-25

I generate LCL/lazutils chm's on request. Last time I can check was during FPC 2.6.4rc1 in nov 2013. Don't know if the one from 2.6.4 ended up somewhere too.

Kostas Michalopoulos wrote

> Shouldn't the CHM files be (re)generated when a full build is made? FPC chm's are generated on every RC and final build. Last is for 2.6.4 and can be found in the doc dir of FPC, dated 2014-02-25

I see. But in the actual Lazarus (Install for Windows) the chm's are from 24.8.2012. I think something was going wrong.

Andreas

The rpms, debs, dmg and zips have chms from September 2013.

Mattias

Which is why i'm asking, shouldn't those be generated automatically for each build? Make it part of the build process, i mean, so there wont be a need to do it manually, have a change to make a mistake or forget some case (like the one with Windows - FWIW mine also mention at the bottom that they were generated on 2 August 2012 and the files have that date) and people who build Lazarus from source will have them out of the box and up to date. AFAIK all the files are there anyway, what is stopping it becoming part of the build?

On Wed, Jan 21, 2015 at 9:54 AM, Mattias Gaertner <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150121/9d66bb56/attachment.html>

Kostas Michalopoulos wrote

Which is why i'm asking, shouldn't those be generated automatically for each build?

Currently the makefile for FPC docs is Unix centric. Which is somewhat clumsy for a windows build. I also think it is not necessary.

The day-by-day maintenance would be much more work then it is worth IMHO. Even if I would propose automated builds, I would decouple docs and snapshot/release generation.
(no snapshot generation because the docs didn't build?)

But in general it is simply a symptom of not doing continuous documentation work, not procedures or whatever. It is simpler to make sure the CHMs are up to date once a release then keeping a more complete build system running on a day by day basis.

p.s. Note that a good sign of seeing if the lcl.chm is any good is to see if the links from the lcl.chm to the rtl/fcl chms are working. Otherwise it is probably a test build

Marco van de Voort wrote

But in general it is simply a symptom of not doing continuous documentation work, not procedures or whatever.

In fact the not "publicly" usable state of the procedures - including the fact that there are different primary-source formats for the several help topics (fpc / rtl / Lazarus IDE / lcl / ...) scare volunteers (e.g. myself) off from improving the help.

-Michael (having been there, wrote some text, abandoned and dumped it.)

Yes, I agree that the Lazarus IDE help should really be removed from the wiki and converted to fpdoc to end this.

Marco van de Voort wrote

Yes, I agree that the Lazarus IDE help should really be removed from the wiki and converted to fpdoc to end this.

I don't disagree, as I just advocate a common primary format for every help that is available from the Lazarus IDE and necessary for creating projects with same.

OTOH I failed on the fpdoc based help authoring procedure.

In fact I did not even got so far as trying to use fpdoc itself. I just tried to build the help file to verify that I will be able to test my would be improvements once I'm done.

Here I failed on the said "procedures" and gave up (dumping the text I already had done in an ASCII editor).

-Michael

Marco van de Voort wrote

(no snapshot generation because the docs didn't build?)

That would be a very good incentive to fix the docs though (not to mention that most likely the build will fail locally before someone submits a change). Someone downloading the snapshot/source from svn will need to have up to date docs, not whenever the last time they were generated. And it will solve issues like how the windows installer distributes two year old documentation.

Of course a no-help build should also be provided since you don't need to generate the help every time you build the code, but normal builds should also build the docs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150122/65b1bbb8/attachment.html>

That assumes people do full release building locally. Usually one doesn't, and only builds the module to test.

Dependencies, timing (CHM generation is SLOW, think 6 minutes for lcl.chm on a i7-3770, though you can halve that with some undocumented multicore enabling hacks) are other problems.

And you know what is said about procedures that are crippling, those raise the most hackles. We want people to do more docs, not to hate docs. Such procedures simply scale badly.

However though adding it to the general procedure is not realistic, setting up a separate release testing (docs inclusive) testbuild system would be doable. Could be integrated with some snapshot generation (of both laz and docs).

This could be done by an user even, since everything relevant is afaik open.

Marco van de Voort wrote

That assumes people do full release building locally. Usually one doesn't, and only builds the module to test.

Aren't full builds made before one submits something to SVN? -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150122/98ccc1cd/attachment.html>

Kostas Michalopoulos wrote

> That assumes people do full release building locally. Usually one doesn't, > and only builds the module to test. Aren't full builds made before one submits something to SVN?

Usually yes. It doesn't make much sense to do a fullrebuild if the change is a type change somewhere in a mysql header.

But in FPC sense, a full build is comparable to a snapshot (make all at toplevel fpcsrc/), which doesn't do several things related to release building. (like docs, zipping information etc).

Generally release builds don't build docs etiher though, and Lazarus building is not part of the FPC procedure at all (of course if problems are expected, nevertheless done)

Michael Schnell wrote

In fact I did not even got so far as trying to use fpdoc itself.

That is strange. I have been using fpdoc for years and many many projects. It works perfectly for many output formats, especially now that fpdoc supports a project file - making documentation building a absolute breeze.

Regards,
- Graeme -

Graeme Geldenhuys wrote

On 2015-01-22 10:12, Michael Schnell wrote: > In fact I did not even got so far as trying to use fpdoc itself. That is strange.

See the current discussion in the German Lazarus forum: Seem not easy at all.

-Michael

Michael Schnell wrote

See the current discussion in the German Lazarus forum: Seem not easy at all.

Sorry, I don't understand German.

All I can add is that I have used fpdoc in small and large (2mil+ lines of code) projects with 100's of units. In all cases I managed to setup and start documenting with fpdoc in a very short time. I've even shown developer how to start the MSEide+MSEgui documentation by creating a fpdoc project file for them and generating "generic" docs in CHM, HTML and INF - all from the same project file. MSEgui is one of the large Object Pascal projects with many units, directories, etc.

My first question would always be.... Have you actually read the fpdoc documentation?

Regards,
- Graeme -

Michael Schnell wrote

See the current discussion in the German Lazarus forum: Seem not easy at all.

By the way... The following URL doesn't show that a German mailing list exists.

http://lists.lazarus.freepascal.org/mailman/listinfo

I guess that could be explained if the German mailing list is not an "official" list.

Regards,
- Graeme -

Graeme Geldenhuys wrote

I guess that could be explained if the German mailing list is not an "official" list.

It's not a mailing List, but an internet Forum:

-> http://www.lazarusforum.de/viewtopic.php?f=13&t=8385

-Michael