Mattias Gaertner wrote:
">
On Sun, 10 Mar 2002 21:20:15 +0100Matjaz Mihelic 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"� :-)
">
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. :-)
">
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. :-)
">
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. :-)
">
- 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.
">
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 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

Matjaz Mihelic wrote

Mattias Gaertner wrote: > >On Sun, 10 Mar 2002 19:17:16 +0100 >Marc Weustink wrote:

[ -- 8< -- ]

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

???

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

What has this to do with C ?

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

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

??? why/what limitid usage

parsed files could be anything .txt,.mac,

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

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

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

Mattias Gaertner wrote:
">
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!") :-)
�
">
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 :-)
">
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. :-)
">
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 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. :-)

">
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. ;-)

">
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 :-\

">
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) :-)
">
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 :-)
">
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 :-)
">
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" ">
Mattias

matjaz

IMO every project should be able to compile with or wihout IDE.

Just a side note:

There will probably no one, that will doubt this statement, because it sounds very principally. But (There is always a But :)

Take for example lazarus itself. You can compile it without the Makefiles. 12 lines with a lot of parameters: cd .. && ppc386 .. && cd .. && ppc386 && remove .. Therefore people invented 'make' and hence you can build lazarus with 'make' (at least, if you got 1.0.6).

The same holds true for the auto-created-units.
A single auto-created-unit can be built by invoking a command line tool (e.g. h2pas, lazres). Together with make you can build a Makefile to do the update checking and invoking the tool to build the auto-created-unit. So, strictly speaking, we already have the tool that is discussed ('make').

We intend to create an update-and-auto-creator (Matjaz called it preprocessor) to simplify the update of auto-created-units. If this thing is integrated in the IDE we gain the advantages of caching, perhaps updating in memory and of course inner program communication, which is always simpler than the command line. And if the user wants to compile his project manually, the IDE could create a Makefile.fpc. This feature is always a good idea, so we will eventually implement it anyway.

What I'm trying to say is: Even if the update check is not a command line tool, but solely integrated in the IDE, this is no disadvantage. You will be able to compile it without the IDE, but it can be more difficult, just as if you are not using make.

Mattias

PS. Building lazarus from the command line isn't that difficult fpc -Fudebugger -Fudesigner -Fiinclude -Fiinclude/linux lazarus.pp should do the trick, but that a difference in the point of view you and I have :-)

Just, before someone is asking:
The difference is of course the definition of 'lazarus' and 'lcl', not the command line. Although it should look somewhat more complex:

ppc386 -Fulcl/units -Fulcl/units/$LCL_PLATFORM -Fucomponents/units -Fudebugger -Fudesigner -Fiinclude -Fiinclude/linux lazarus.pp

Mattias

Mattias Gaertner wrote:
">
On Sun, 10 Mar 2002 19:17:16 +0100Marc Weustink 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 :-\
">

2. Open main program file and gather uses clauses trough hierarchy avoiding redundancy (nothing simpler than that)

OW?

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 me

Remember two facts, this files will be standalone and pascal community doesn't like to make C-like_code

">

[...]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
">

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 :-\
">

[...]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 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,
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"} 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 :-)

">

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) :-)
">

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? :-)
">

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:-\
">
Good idea.Mattias

matjaz

There you have a point.

Marc

PS. Building lazarus from the command line isn't that difficult fpc -Fudebugger -Fudesigner -Fiinclude -Fiinclude/linux lazarus.pp should do the trick, but that a difference in the point of view you and I have :-)

Hmm.. I like this approach. It might be usefull. Might, since I haven't seen a .h to .pas convertor which was usefull.

OW?

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.

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.

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.

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

Looks like macro recording.

Hmm... something like:

Unit Cheetah;
{#AutoCreateUnit}
{#Files "cheetah.h"
{#PlayMacro "do_some_replacemnts"}
{#Execute "yyytool -option1 %s"}

Marc

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.

>2. Open main program file and gather uses clauses trough hierarchy >avoiding redundancy (nothing simpler than that) OW?

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.

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?

Messages from the preprocessor like errors and warnings should go to the messages window like any other compiler/codetools message. Right?

Sounds like dpkg-deb.

Looks like macro recording.

Yes, something like that.

Good idea.

Mattias

Sometimes, I got the feeling, my english will never be good enough to understand all this metaphers...

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

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.

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.

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

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.

:)

It would confuse the user, if these messages would _not_ go to the same window ... ;)

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

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.

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

There is always a better solution. (c:

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

Never mention <include> directives in c style and talk about a preprocessor in a pascal community. It is a deadly sin. ;)

Mattias

On Sun, 10 Mar 2002 21:20:15 +0100
Matjaz Mihelic wrote:

Let's unstuck the bee and start a new thread for external codetools or whatever they will be called.

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

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.

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} Where to put the other parameters? Maybe a config file, maybe into the directive.

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
- messages (errors, warnings, ...)

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