[lazarus] external codetools / copycat equality

Matjaz Mihelic matooo at email.si
Sun Mar 10 20:15:12 EST 2002

Mattias Gaertner wrote:
20020310213838.2bb59bc7.nc-gaertnma at netcologne.de">
  On Sun, 10 Mar 2002 19:17:16 +0100Marc 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 work1. 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.
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 :-\ 
          20020310213838.2bb59bc7.nc-gaertnma at netcologne.de">
                2. Open main program file and gather uses clauses trough hierarchy avoiding redundancy (nothing simpler than that)
                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))
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
Remember two facts, this files will be standalone and pascal community doesn't
like to make C-like_code
                20020310213838.2bb59bc7.nc-gaertnma at netcologne.de">
                    [...]To be short, there are 2 ways1) in the uses clause   {#activate "yyytool --parameters"} newname2) 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"} newnameUnit2 uses {#activate "yyytool --parameters ZZZ"} newnameUnit3 uses {#activate "yyytool --parameters ZZZ"} newnameWill 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 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
                    20020310213838.2bb59bc7.nc-gaertnma at netcologne.de">
                            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?
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
                                  20020310213838.2bb59bc7.nc-gaertnma at netcologne.de">
                                      [...]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.
Advantages are, limited usage (speeds up and simplifyes preprocessor), parsed
files could be anything .txt,.mac, 
unit cheetah;
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"} newname
and macro is invoked :-)  and
you can still say something like
                                        {#activate "parsemacro --parameters XXX"} newname
so this macro could be far more complex :-)
                                        20020310213838.2bb59bc7.nc-gaertnma at netcologne.de">
                                              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/questionWhat 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?
Yes, that's why I suggested same Error reporting as fpc (so you wouldn't
need zillion lines to implement) :-) 
                                              20020310213838.2bb59bc7.nc-gaertnma at netcologne.de">
                                                      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 -> HandleDevContextRegular Expr Search and Replace: \bhdc\b -> HandleDoing 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&Replace2.Search&Replace3.Comment: Doing some special tricks3.h2pas4.insert textAfter a few mo
nths 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. 
Isn't that nice? And simple? :-) 
                                                          20020310213838.2bb59bc7.nc-gaertnma at netcologne.de">
                                                              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"}
I guess now I'm not the one that's getting C-like. Why so much commands,
when tools are special and there is a separate tool for every job done????
 :-\  And why so much complexity, when most powerfull solutions
are always the simplest. Simplicity means less lines of code.
 :-\  No need to reprogram NASA infrastructure
Guess, I'll go back to coding after this message. I'll follow how you'll
decide and try to help afterwards with some tool maybe, I've got really busy
week in front of me:-\ 
                                                                        20020310213838.2bb59bc7.nc-gaertnma at netcologne.de">
                                                                          Good idea.Mattias

More information about the Lazarus mailing list