[fpc-devel] MakeSkel and FPDoc projects

[michael.vancanneyt at wisa.be]

On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:

> Michael Van Canneyt schrieb:
>
>> 
>> Feel free to create this program. If I may give some advice: the tasks you 
>> outline belong in a "Documentation writers IDE".
>
> To some degree, maybe. But checking for updates should be doable by a script, 
> without a need to open an IDE - for every single package!

I have done so for years, with the existing tools, using the Makefiles. 
No changes were necessary.

So you'll hopefully excuse me if I think you are seeking problems where there are none...

>> I will cooperate on additional options which enhance the operation of the 
>> tools within the frame of their purpose, as I have done recently. I think 
>> that makeskel can be enhanced to use a project file to create an update for 
>> a single unit file, to spare you the effort of typing all options again, 
>> but that's about it.
>
> This would be very kind, of course :-)
>
> Can you also add this option to FPDoc, so that it will allow to do a test 
> build for an single unit file?

Yes, this was already planned.

> Consider what happens when FPDoc, MakeSkel or MkFpdocProj *update* a project 
> - a new file will be created, that contains whatever the programs have 
> extracted from the input project, and whatever else they find worth to store 
> in the output project. When they do not update the projects themselves, how 
> can the user be informed of possible changes, so that he can update the 
> project file himself?

That is where your IDE jumps in.

> Currently changes to the RTL and FCL (MakeFiles) require a dry-run of make, 
> analysis of the resulting commandline, and a manual merge with the existing 
> project. According to the Unix philosophy another tool is required, that 
> automates the project file update, and one more for updating the project file 
> when description files are added...

According to Unix philosophy, the person doing so is aware of what he is doing,
and makes the necessary changes (if there are such changes) to the project file 
himself.

I do not believe the tools can make the correct decisions, except in the
most trivial circumstances.

>> 2. If command-line options override the defaults in the file (as they do),
>>    you just need to specify the correct options on the command-line in case 
>> the
>>    project file contains the wrong ones.
>
> This means in practice that almost all settings have to be given on the 
> commandline (except the file lists), or to inspect every single project for 
> the contained settings, in order to find out what must not necessarily be 
> overridden.

Of course. No tool can do this for you, for the very simple fact that
computers are very stupid. They can help you organize your life, but they 
do not organize your life for you. You are in the driver's seat, not the
computer.

> But 
> when I have to use Lazarus with different settings, for building applications 
> (last release or trunk, with or without patches for a dockable IDE), and for 
> different FPC versions (e.g. trunk for building the documentation tools), 
> life can become very complicated :-(

No doubt. 
But instead of blaming the tools, maybe you should reconsider the way you
organize your work. I have many versions of FPC and Lazarus floating around,
on various platforms. I seem not to have all these problems you are
experiencing, yet I use the same tools.

So excuse me for believing that the problem is not in the tools :-)

Michael.