[lazarus] About ***compatibility??? wrong term, originally I ment copycat equality??

Sat Mar 9 15:18:24 EST 2002

This message is ment for all, that were involved in "About compatibility???"
 thread

Mattias Gaertner wrote:
20020309192432.5e549ea4.nc-gaertnma at netcologne.de">
  On Sat, 09 Mar 2002 15:19:35 +0100Peter Vreman <peter at freepascal.org> wrote:

    Also the {$useheader xx} is something that will never make it into the compiler. We are a pascal compiler not a C compiler.

    Thx god.

You're not the only one that thanks god.  :-D

Even though I suggested that option, you've made a bit too much fuzz. One
of the parts of project I'm working on, is fairly connected to that option.
This includes parsing other language sources to some limit. Something like
.h files were only one of the options >>> Other one would be easy
translate of strings in some const unit in some other language by using some
good external command (language translator) line solution. Please don't make
fuzz of this again, but there could also be a fairly nice pascal const file
to preprocess. Or a text file, or XML, or name it. 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. :-) 

You've stuck with this idea of parsing C headers, like a <bee on a honey
"*ouch, hammer spell checker in progress">. Why, when there is no limits,
the only need is to carefully design external model that IDE would support.
     :-P 

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 what 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 "....".
 :-( 

Originally I was reffering to option, to have user defined preprocess function
in IDE. "It was said that it would be possible". Ok. 
 :-P 

Idea was to have some Codetools option that would parse use external software
to preprocess. That part wasn't agreed. Ok.
:-) 

I admit I'm guilty by choosing some bad example, and bad description. Just
like the Compatibility question. Read that term as:> Why bothering to
make a copycat Delphi? We can make 100%compatible and better without question.
 :-[ 

EWrappers and other Component extensions I was suggesting, will be posted
somewhere next week probably (Depends on free time I'll have in next week).
I'll post them as elf executable, as program source - well comented and well
comented changes I'm suggesting. I'm not trying to <be a mosquito "*ouch,
hammer spell checker in progress">, I'd like to make some mistakes that
Borland made go away, to give the lazarus users much cleaner code. 
 :-\ 

Parser tools I'm doing my work on would be posted same way. I wasn't asking
for solution I was asking for option. :-( 

I felt preety dissapointed of fuzz, that suggestion made. Dissapointment
goes to me, for a stupid example :-( 
    20020309192432.5e549ea4.nc-gaertnma at netcologne.de">

        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">. 
 :-( 
        20020309192432.5e549ea4.nc-gaertnma at netcologne.de">
          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.
 :-\ 
          20020309192432.5e549ea4.nc-gaertnma at netcologne.de">
            Mattias_________________________________________________________________     To unsubscribe: mail lazarus-request at miraclec.com with                "unsubscribe" as the Subject    archives at http://www.miraclec.com/list_archives/lazarus

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

matjaz