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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
