[lazarus] external codetools / copycat equality

[Marc Weustink]

At 02:17 12/03/2002 +0100, Matjaz Mihelic wrote:
>Mattias Gaertner wrote:
>>
>>On Sun, 10 Mar 2002 19:17:16 +0100
>>Marc Weustink <mailto:marc at dommelstein.net><marc at dommelstein.net> wrote:
[ -- 8< -- ]

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

IMO every project should be able to compile with or wihout IDE.
>Yeah, I guess reading a fpc config would take like an hour and take a 
>zillion lines of code??? And yes, general idea is CLI interface but 
>integrated in lazarus same way as compiler :-\

???


>>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.
>>
>Yes, with codetools it would be, and no, my way it would be just simple 
>file parsing, without need of simulating pascal compiler (this is main 
>reason why I'm suggesting uses clause, to avoid preprocessor complexity, 
>one command only (put macro in separate file if you need you can invoke 
>macro with a tool that processes macros))

Using the uses clause or putting thing in a header makes no difference.

Simple file parsing in your way only exist for simple files. I can imagine 
valid pascal files where a simple scanner completely goes wrong.

what about:

uses {#activate "yyytool --parameters XXX"} newname;

uses
{$IFDEF something}
   {#activate "yyytool --parameters XXX"} newname;
{$ELSE}
   otherunit;
{$ENDIF}

uses
   // {#activate "yyytool --parameters XXX"} newname,
   otherunit;

etc...

>Respecting pascals strict syntax means limited usage (not garbaged like 
>C), strict syntax is main reason I love pascal, I can read the code I 
>writen after a month  :-)
>
>uses {#activate "yyytool --parameters XXX"} newname;  *****seems good to me
>
>Remember two facts, this files will be standalone and pascal community 
>doesn't like to make C-like_code

What has this to do with C ?

>>>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.
>>>
>That's what base preprocessor should decide in first place, scan source 
>for directives, remove duplicates

So it isn't a plain simple preprocessor. And why add these 
difficulties/possible errors if you can avoid it at one spot, the unit header ?

>and after that activate appropriate tools to create this files :-) 
>Preprocessor should be only queue for activating tools in this case, not a 
>tool. Then on the other hand it could just generate error and inform about 
>duplicating with different parameters

Why bugging ppl with possible duplicates. If youre using the uses clause, 
for every instance your declaration has to be the same. You can't place it 
at one spot (in a later stage one can decide that the requested unit isnt 
needed for that unit) and if you place them at every instance, you have to 
keep them in sync. Nice option if I have used this at 20 places in my code 
and need to change one parameter in the options passed to the tool. This in 
not VB!

[ -- 8< -- ]

>>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?
>>
>Yes, after first compile you already have a pascal unit. I admit before 
>compiling this units are unknown. But after that, you have plain pascal 
>units and codetools already supposed to do this job, processing pascal 
>code. ;-)
>So, why would you invoke preprocessor from IDE??? It will do his job after 
>first compile, invoking it seems like a waste to me :-\

While editing  you might want to invoke code kcompletion, you micht want to 
see the delcaration if the new function you are using etc.

>>>>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.
>Advantages are, limited usage (speeds up and simplifyes preprocessor),

??? why/what limitid usage

>parsed files could be anything .txt,.mac,

so... with the header option as well.. I see no difference

>Yours
>
>unit cheetah;
>interface
>...
>implementation
>...
>end;
>
>would be automatically generated, no need for user to create one.
>Instead of creating this file user only needs to specify
>
>uses
>{#activate "yyytool --parameters XXX"} newnameand macro is invoked 
>:-)  and you can still say something like
>
>{#activate "parsemacro --parameters XXX"} newnameso this macro could be 
>far more complex :-)

Shocking :-)

[typing one line] vs. [typing one line in a new file].

With the second one having the advantage that the user makes less errors 
and is easier to maintain.

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

Question remains.
[ -- 8< -- ]

>>>Hmm... something like:
>>>
>>>Unit Cheetah;
>>>{#AutoCreateUnit}
>>>{#Files "cheetah.h"
>>>{#PlayMacro "do_some_replacemnts"}
>>>{#Execute "yyytool -option1 %s"}
>I guess now I'm not the one that's getting C-like.

Tell me what C-language do you use ? :)

>Why so much commands, when tools are special and there is a separate tool 
>for every job done???? :-\

It is an example of options one has if using this. At this point I don't 
want to think of all pros and cons of an example. Writing these replies 
consumes enough time.

>And why so much complexity, when most powerfull solutions are always the 
>simplest.

It would be complex if I gave a coplete example with conditional statements 
jumps etc. That what I wouls call complex. This, IMO is of the same 
complexity as parsing a whole comment line with different statements.
The only fun is, this wa it is more readable.

>Simplicity means less lines of code. :-\  No need to reprogram NASA 
>infrastructure

No need for that, NASA infra won't play macros :)

Marc