[lazarus] external codetools / copycat equality

[Mattias Gaertner]

On Mon, 11 Mar 2002 04:33:22 +0100
Matjaz Mihelic <matooo at email.si> wrote:

> >So much text, and still so many questions...
> >
> >Hopefully, I understand you right this time:
> >1. You want to automate for example the conversion of foreign language code to pascal by command line tools.
> >2. This automatic tools will create part of pascal units or whole pascal units. For example the lazres tool converts binary files to pascal code.
> >3. These tools should be integrated into the IDE.
> >4. The "only" question is, how should they be integrated.
> >
> Yep, as you just pointed one question, "how...if it would be possible"  :-)
> 
> >
> >Parameters to the external codetools:
> >All tools need some parameters and/or piped sources to work with.
> >Your suggestion was a directive in the pascal code. 
> >Something like {$AutoCreateUnit h2pas -d -v header.h}
> >
> could be that you just struck the 220volts and turn me some light. ;-) 

Sometimes, I got the feeling, my english will never be good enough to understand all this metaphers...


>  Look at this way
> yyytool --configure    ->    Put that in tools There's a configuration 
> dialog
> uses
>   Linux,
>   Classes,
> {#activate "yyytool --parameters"} newname,
>   Otherunits;
> 
> Activates yyytool with parameters and produces same output as compiler. 
> Would be nice to change {$ to something else to separate preprocessor 
> directive from compiler directives. :-)

I see some problems, putting the directive into the uses clause:
All units, that uses the auto-created-unit needs this directive with all the implications of redundancy. Also the update checker would become somewhat more complex.
Here is another solution:
Since we are auto creating only whole units, why not put the directive and the parameters right into the destination unit. For example: there is an auto created unit cheetah.pas. The  header looks like the following:

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


The user has told the IDE to check this unit for auto creation.
Then, each time before the project is compiled, the IDE checks all auto created units, if they need update.

The advantage is, that the auto created unit is independent of higher units, that uses the auto-created-unit and the we can't get redundancy. But the most important thing is: There is always a source, so that find declaration would work. Also the preprocessor would become more simple.


Creating an auto-created-unit is simple:
1. create new unit
2. tell the IDE, that it is auto created
3. Add a directive to the source

Using the auto created unit in another project is simply done by using it. And if you want to invoke the auto update in another project too, than you can just add them to the project specific list of auto-created-units.



> >What is produced:
> >- Pascal units
> >
> [...]so what it 
> would concern IDE wouldn't change a bit except calling two compiling 
> commands instead of one. Most unpainfull change. :-)

:)


> >- messages (errors, warnings, ...)
> >
> Best would be use the same window as you use for compiler, and there 
> could be arranged that error messages by these tools would produce 
> results same way as compiler does so would be working even selecting of 
> error line in that file and you already coded that part, so if the 
> results would be the same.... :-\

It would confuse the user, if these messages would _not_ go to the same window ... ;)


> I could extend a little bit my part and make preprocessor.
> *Call preprocessor just as you would call compiler
> *    PREP:Read lazarus configuration
>     PREP:Read units folders
>     PREP:Preprocess files in same folders as they are. As you have said 
> learning tool for converters could be invoked when converting.

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.

That is just my idea, how it can work. The Frontend will be generic enough, to handle other tools than h2pas as well.


> [...]
> Most important is not to burden lazarus with that too much, since 
> project is good even without that. All should be as unpainfull as 
> possible. I think I've got here the best option to respect that.

There is always a better solution. (c:


> [...]
> now I'm relieved, pascal society won't suffer because one good idea 
> pointed out with stupid example. :-) :-) :-)

Never mention <include> directives in c style and talk about a preprocessor in a pascal community. It is a deadly sin. ;)


Mattias