[lazarus] external codetools / copycat equality

[Matjaz Mihelic]

Mattias Gaertner wrote:
20020310095350.2b4711d7.nc-gaertnma at netcologne.de">
  Sometimes, I got the feeling, my english will never be good enough to understand all this metaphers...
  
Ok, none of them anymore (It ment "While I was reading your comment, I accidentally
think of simpler way to aproach to this problem, so concept of this new idea
is generally your own reply, Thanks!") :-) 
 
  20020310095350.2b4711d7.nc-gaertnma at netcologne.de">
    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...
    
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)
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 :-) 
    20020310095350.2b4711d7.nc-gaertnma at netcologne.de">
      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.
      
No need for IDE to check that one, IDE would need only to start the preprocessor
engine and gather results. :-) 
      20020310095350.2b4711d7.nc-gaertnma at netcologne.de">
        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.
        
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. 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. :-) 
        
        20020310095350.2b4711d7.nc-gaertnma at netcologne.de">
          Creating an auto-created-unit is simple:1. create new unit2. tell the IDE, that it is auto created3. Add a directive to the sourceUsing 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.
          
User shouldn't do that, 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.
 ;-) 
          
          20020310095350.2b4711d7.nc-gaertnma at netcologne.de">
            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. 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
 :-\  
            
            20020310095350.2b4711d7.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 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????
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)
 :-) 
              20020310095350.2b4711d7.nc-gaertnma at netcologne.de">
                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
 :-) 
                
Like first I suggest something like that
tool --configure >> would invoke configuration of that tool to specify
its parameters (easy to include in tools menu)
tool --new >> would either invoke editor if command line would specify
it's own or return something like CreateNewFile and that file would be edited
by lazarus
tool --open [filename] >> same as new
tool --version >> says it's self
tool --description >> Writes out describtion about this tool (aka.
usefull for about tools, or menu options)
Other would be like tool specific and wouldn't matter since they would be
specified in invoke command :-) 
                
Imagine standalone frontend to h2pas easy plugable in lazarus and with capability
of learning and interactive editing :-) 
                20020310095350.2b4711d7.nc-gaertnma at netcologne.de">
                  There is always a better solution. (c:
                  
Every message produces it in this case, but I think it's time to set a concept
"who and how" to do the job, not to talk about ideas and extensions anymore,
it could go forever (and at the end we'd probably get whole NASA infrastructure
in one comandline). Like I said already, I could start on this as soon as
my first extension(Wrappers, that baby of my own is just too important to
me) will be ready, in a week or two :-) 
                  
I can do it, you can do it, I guess anybody could... Who it will be? I'm a
willing candidate, but first let's just decide which method and how it will
be implemented :-) 
                  20020310095350.2b4711d7.nc-gaertnma at netcologne.de">
                    Never mention <include> directives in c style and talk about a preprocessor in a pascal community. It is a deadly sin. ;)
                    
I'm still praying for my soul not to go to hell
 :-D  ***JOKE, NOT CURSING, VALID USAGE OF WORD "HELL"
                    20020310095350.2b4711d7.nc-gaertnma at netcologne.de">
                      Mattias
                      
matjaz