[lazarus] external codetools / copycat equality

Sat Mar 9 22:31:24 EST 2002

Mattias Gaertner wrote:
20020310024110.3f5bf7a8.nc-gaertnma at netcologne.de">
  On Sun, 10 Mar 2002 21:20:15 +0100Matjaz Mihelic <matooo at email.si> wrote:Let's unstuck the bee and start a new thread for external codetools or whatever they will be called.

    [...] There is no limits. ;-)Main example of idea really was <#include somelibrary.h>. That would call h2pas or any other translator and if it goes, it goes, otherwise I thought it would produce compiling error, but the idea with some learning converter as suggested bellow is fantastic. :-)[...]Specifiying in some dialog <#includeheader %1> = h2pas to activate that preprocessor function or anything is nice. Generates something like "BHhbdfhjydsgts.pas" and replaces <#includeheader> with normal uses this new file.Having set language parameter in outer converter and specifiying <#includelanguage> and have this resource strings compiled in some other language. All except this IDE internal preprocessing is something what's already possible to solve with Tools menu. I reffered either to piped preprocessor, or direct to some file or anything. This option is something wha
t concerns IDE, and not compiler. C seemed to me like a good example, but now I see it was the worst possible because of never ending "pas & c battle" or "limitations" or "....". :-([...]Idea was to have some Codetools option that would parse use external software to preprocess. That part wasn't agreed. Ok. :-)[...]

        IMHO an option for h2pas in the IDE is not that usefull, it can only be used for very simple .h files not for complex things like gtk/gnome.

        Just to avoid misunderstandings:The frontend I have in mind, will be something of a dialog to easily manage the h2pas options and add some functions to the IDE, to make the boring search&replace easier, which is often needed before/after applying h2pas.These options and editing steps can be saved to a file, so that the next time a newer version of the header files can be converted faster.

        Please say that you mean external, not internal part, see your first comment. I don't wanna be blamed by the society for giving a bad example, that made pascal get <bad name "*ouch, hammer spell checker in progress">. :-(

        'course will h2pas stay external. Like compiler an debugger.I'm also planning to add frontends for the other fpc tools. 

            I think, this could help to accelerate the conversion process.Of course I'm not a c to pascal conversion crack, and I don't know any such frontend, so I need some help to gather good ideas, what functions are needed for c to pascal conversion.

            Yes, I've got the ideas to the solution (your learning kind of solution would boost them indefenitelly :-P ), somehow it would be 2nd step of my project, but with codetools easy included (and they will be *external (command line without question) and CVS, maybe if approved even part of lazarus since I'm writing them directly for lazarus), so it's far from polished state. A month or two maybe as for my case. :-\
            Carefull explanaton:1. Again >>>>>>>> my question was made for IDE and not compiler, if it would be ment to compiler www.freepascal.org would be the right place. Question is about Codetools supporting some external model of user defined preprocessing, which on the other hand could make to be included with IDE if approwed. <<<<<<<< :-(2. I wasn't asking for specific solution, I was asking for possibility to the solutions like this :-\3. Correct me if I'm wrong, but LCL units are not part or freepascal, so anyway changes I suggested go to LCL ;-)4. Reason why parsers will be external. I don't wan't to slow down project lazarus, it's simply too good and as external they'll have much more options and easyer updating. :-\

            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" 
 :-) 
            20020310024110.3f5bf7a8.nc-gaertnma at netcologne.de">
              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.
 ;-)  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. :-) 
              20020310024110.3f5bf7a8.nc-gaertnma at netcologne.de">
                Where to put the other parameters? Maybe a config file, maybe into the directive.

Wherever, doesn't really mind. Since external configuration tools could configure
that one. :-) 
                20020310024110.3f5bf7a8.nc-gaertnma at netcologne.de">
                  When should the external codetools be invoked:Only if the input changes. That means the IDE needs to recognize, if the last output is older than the input files. For example, if the output file is a unit, which is older than the input file, then the IDE would automatically invoke the tool, when the unit is needed during compilation (similar to make). In this case, auto created units are readonly.What is produced:- Pascal units

Would be the best, altough I think that's why would we need preprocessor
that would follow sources and precompiled them, so instead of calling compiler
you'd just call preprocessor with same directive as compiler. If preprocessor
strucks error you don't even compile it, so what it would concern IDE wouldn't
change a bit except calling two compiling commands instead of one. Most unpainfull
change. :-) 
                  20020310024110.3f5bf7a8.nc-gaertnma at netcologne.de">
                    - 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.... :-\ 

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.
                    If error happened write output threated as compilers
output
If not Plain compile as preprocessor wouldn't existed (all preprocess files
are generated so this is normal program, and because preprocessor directive
gets read as comment from compiler side and new file exists there's no problem).

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.
                    20020310024110.3f5bf7a8.nc-gaertnma at netcologne.de">
                      I'm still not happy with the directive in the source, since I prefer a nice dialog, but perhaps I still misunderstood you. I like the idea of auto created units, although I'm not sure about the how.Mattias_________________________________________________________________     To unsubscribe: mail lazarus-request at miraclec.com with                "unsubscribe" as the Subject    archives at http://www.miraclec.com/list_archives/lazarus

Results:
1. Almost no new code needed :-) 
2. Everything is almoust solvable in lazarus as is now, except invoking the
preprocessor :-D 
3. I'll try to put preprocessor together as soon as possible and then we
could give it a try :-) 

Limitations:
1. No macros as pascal is supposed to be a nice clean code
 :-) 
2. All preprocessor directives should be in uses statement
 :-\ 

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

matjaz