[lazarus] external codetools / copycat equality

[Marc Weustink]

At 18:01 11/03/2002 +0100, Matjaz Mihelic wrote:
>Mattias Gaertner wrote:
>>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
>>...

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.
>2. Open main program file and gather uses clauses trough hierarchy 
>avoiding redundancy (nothing simpler than that)

OW?

>2.1. Since this is only information gathering, there's nothing simple as 
>checking if you've already checked that file or not (no redundancy problem)
>2.2. Found files (preprocessor script that will be invoked) in need of 
>preprocessor checking are selected by
>2.2.1. Result unit does not exists yet
>2.2.2. Compiled (Result) unit is older than original file
>2.2.3. Build all was invoked
>2.2.4. To avoid duplicating check wheter preprocessing command for that 
>file does not exists yet in preprocessor script or file with same name is 
>created different way more than once
>3. List of preprocessor commands is generated, preprocessor has command list
>4. Invoke the commands (here is where the complexity is, but this is 
>external and controlled process)
>5. Exit with status same as fpc
>5.1. Error was produced, so you can't compile, it wouldn't compile since 
>units would be missed, that part is known already, so don't invoke 
>compiler, invoke same error as you do for compiler and you can change 
>title fom "Compiler messages" to "Preprocessor messages", if there's no 
>errors, but there are preprocessor warning messages you can just start 
>line PREPROCESSOR WARNING: in compiler messages Window
>5.2. It worked, so call the compiler :-)

That how it would generally work.

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.

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

Indeed.
>Yep, it's a standalone unit, and that's the main reason why it would work 
>well in uses clause. Let's say that somebody would invoke compiler out of 
>IDE. He'd just get "File not found" for the first unit that would need 
>preprocessor for it's creation. But on the other way he could invoke 
>preprocessor first and compiler next, what will lead to succesfull compiling.
>
>Good thing is that is preprocessor would not change main sources at all, 
>since all the preprocessor directives are "{#Comments}" ;-) . Compiler 
>wouldn't even need to know there is some preprocessor. 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.

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

Hey, where have I read this :)

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

Or, if you've used the IDE add unit option, the IDE has found out itself.
>User shouldn't do that,

Why not.

>if we use my way, all he'd need is to create file that needs 
>preprocessing, that's where lazarus would be important to make this list 
>of tools visible to user (aka. File -> New -> (Submenu with list)X 
>preprocessed resource) and invoke some special editor maybe. But to get 
>there is still far. It's explained at the end with parameters :-)
>
>So let's say: My proposition is>  Let's code shell preprocessor (one that 
>walks trough while code with one simplex tool, tool that creates specified 
>blank unit (with simple configuration, maybe starting comment??)), and 
>then all that's needed is to figure out what would be the best option to 
>implement tools features in lazarus as a shell concept for preprocessor 
>tools. ;-)

>It would confuse the user, if these messages would _not_ go to the same 
>window ... ;)
>Hey, you are talking about people coding the software not some secretary 
>using it.

You'll be surprised :-)

>This people should now the difference since they know how to code, but as 
>you see steps I specified there's no need to do that :-\

PPL using software should know.....

>>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
>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????

Looks like macro recording.

>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 (and 
>since lazarus would be unaware that anything is happening if tool would be 
>enough smart to provide interactive interface, then your idea turns good, 
>very good) :-)

>>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.
>>
>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"}



Marc