[lazarus] external codetools / copycat equality

Mattias Gaertner nc-gaertnma at netcologne.de
Sun Mar 10 15:34:06 EST 2002

On Sun, 10 Mar 2002 19:17:16 +0100
Marc Weustink <marc at dommelstein.net> wrote:

> [...]
> >>// This unit is automatically created, plz don't edit. All your changes 
> >>will be lost.
> >>Unit Cheetah;{#AutoCreateUnit InputFiles="cheetah.h" Command="yyytool 
> >>-option1 %s"}
> >>
> >>Interface
> >>...
> Hmm.. I like this approach. It might be usefull. Might, since I haven't 
> seen a  .h to .pas convertor which was usefull.
> >No, there is no problem, since preprocessor is simple tool, tools can be 
> >complex. Here are steps needed for preprocessor (my opinion) to work
> >
> >1. Gather fpc and lazarus information concerning unit directories, include 
> >directories, etc.

The codetools saves this information in the TDefineTree, which can be seen in Environment->'CodeTools Defines Editor'. So, the IDE has already this information. No need for the preprocessor to gather it a second time. Except you want the preprocessor to be runnable without the IDE, which, I thought, was not intended.

> >2. Open main program file and gather uses clauses trough hierarchy 
> >avoiding redundancy (nothing simpler than that)
> OW?

Reading just one single line of pascal (e.g. the uses line) requires full support of compiler directives, emulation of the complete file search algorithms of the compiler and a lot more. Not just checking some file dates. Of course you can just use the codetools units, but that would be redundancy again. 

> [...]
> To be short, there are 2 ways
> 1) in the uses clause
>    {#activate "yyytool --parameters"} newname
> 2) in a unit header.
>     Unit Cheetah;{#AutoCreateUnit InputFiles="cheetah.h"
>       Command="yyytool -option1 %s"}
> I think the last one has less problems and is safer to use. Think of option 
> one and 3 different units in the came project.
> Unit1 uses {#activate "yyytool --parameters XXX"} newname
> Unit2 uses {#activate "yyytool --parameters ZZZ"} newname
> Unit3 uses {#activate "yyytool --parameters ZZZ"} newname
> Will for each case a new file be created ? Or will the file be reused ? And 
> what if the parameters change for that file, you have to update them all.
> >>The user has told the IDE to check this unit for auto creation.
> File, New, Autocreated unit, show dialog to enter params.
> >>Then, each time before the project is compiled, the IDE checks all auto 
> >>created units, if they need update.
> >No need for IDE to check that one, IDE would need only to start the 
> >preprocessor engine and gather results. :-)
> Indeed, not stricly needed by the ide, but since it has the information, it 
> might besomewhat faster.

It will check in either case. For find declaration, which is invoked several times more often than a compilation, the IDE needs the information. So, if the preprocessor would do the checking, it will be invoked not only just before a compilation, but before each find declaration. How do you want to do that in good time?

> [...]Don't think that I 
> >don't agree with extra unit. But using the advantage of uses clause we'd 
> >get rid of this extra files and main source file wouldn't need to be 
> >changed at all.
> In both cases you would have to have that extra unit. In both cases it is 
> generated. I still see no advantages of putting the derective in the uses 
> clause.
> >This generated files should really exist, not to be a fiction of any IDE. 
> >IDE should be just automated tool to use that option, so nobody compiling 
> >from command line wouldn't be ripped of that option. :-)
> Ofcourse does the file exist. The IDE only invokes an external compiler as 
> if someone invoked it from the commandline.
> When using commandline, one should invoke the $yyytool which parses all 
> uses clauses and generate the needed files.
> When using the IDE it can be somewhat faster since the IDE knows what files 
> have to be created so it invokes $yyytool with the option to generate a 
> requested file.
> Another thought/question
> What to do if the generated unit requires a uses lause itself ?
> For option 2 (the unit header) I can imagine some solutions.
> [...]

Messages from the preprocessor like errors and warnings should go to the messages window like any other compiler/codetools message. Right?

> >>Perhaps "learning" could be confusing for users.
> >>It is merely an editing command list. Consider the following scenario:
> >>
> >>A programmer starts to convert a c header file to a pascal unit.
> >>He reads the .h files and decides to change some things before he will 
> >>invoke h2pas:
> >>Regular Expr Search and Replace: \bHDC\b -> HandleDevContext
> >>Regular Expr Search and Replace: \bhdc\b -> Handle
> >>Doing some specials tricks.
> >>The user should manually add this commands via the Conversion Frontend. 
> >>The Frontend will help him, by showing him the history list of all 
> >>search&replace calls.
> >>Then he calls h2pas with some options.
> >>After that he applies an additional comment to the unit.
> >>He saves the editing list, which looks like the following:
> >>
> >>1.Search&Replace
> >>2.Search&Replace
> >>3.Comment: Doing some special tricks
> >>3.h2pas
> >>4.insert text
> >>
> >>After a few months he wants to update his unit. Instead of thinking "Oh 
> >>no, not again this damn c code", he loads the file and can replay the 
> >>list step by step and can see, if the new c header files needs some extra 
> >>or not.

> >I guess it could be even more interacitve and easyer to manage if this 
> >coummand line would actually ask what to do in that case and remember that 
> >decision????

Sounds like dpkg-deb.

> Looks like macro recording.

Yes, something like that.

> >And it would be completely tool based. So we wouldn't stuck with same 
> >fromtend for every job. Idea is good ;-) but in this case there could be 
> >to much difference between jobs to satisfy them all with single based 
> >interface :-\  so I think there should be interface as you said but used 
> >if tool doesn't specify it's own during it's runtime while processing
> [...]

> >>That is just my idea, how it can work. The Frontend will be generic 
> >>enough, to handle other tools than h2pas as well.
> >>
> >What I ment with learning was same thing, we just used different terms. 
> >And scenario is good. But the idea goes even further, imagine to have 
> >other converters with same command line parameters doing something 
> >completely different (but in the end pascal unit is what we get, 
> >mathematicaly said TOOL+FILE_NEEDED_TO_BE 
> >_PREPROCESSED=STANDALONE_PASCAL_UNIT) with different frontend to configure 
> >and maintain. All what is needed is a specification of command line 
> >parameters :-)
> Hmm... something like:
> Unit Cheetah;
> {#AutoCreateUnit}
> {#Files "cheetah.h"
> {#PlayMacro "do_some_replacemnts"}
> {#Execute "yyytool -option1 %s"}

Good idea.


More information about the Lazarus mailing list