[lazarus] About compatibility???

[Matjaz Mihelic]

Mattias Gaertner wrote:
20020308104631.5c61c60b.nc-gaertnma at netcologne.de">
  On Fri, 8 Mar 2002 09:43:14 +0100 (W. Europe Standard Time)Michael Van Canneyt <michael.vancanneyt at wisa.be> wrote:
  
    
      Since it is impossible to translate any c header file to good pascal code, the current h2pas is the better solution.I would like to add a h2pas frontend to the IDE, so that using c libraries will become much easier. But before that, h2pas must be improved.
      
      What is missing in h2pas ? (except a preprocessor :) )
      
      :)If someone does that, I will write a frontend for it.
      
      
What is missing?? Let's look at the thing from the right angle. I've got
somelibrary.1.1.2. Somebody else is having somelibrary.1.1.1. This two versions
are not necesarilly compatible. But the case is the guy that made header
translatoion had 0.3.1. Then he somehow stopedd posting updates. We lose
nobody gains.
      
My suggestion is to go dig deep further. Combine preprocessor with gcc or
make this bastard, does something like that, so unit headers would be obsolete.
Every got dam'n lib comes with devel. We'd gain instantly access to whole
api. 
      
Let's see now there will be gtk2, how long will it take to translate headers,
half of the time to gtk3, we always lose. We could do some good thing. 
      
Get API in time with other developers, combine our resources with theirs,
and be able to do something more than we do now is what I'm thinking.
      
Other example. File formats... would you say that your own implementation
of png will be better than png. Accessing OpenOffice documents and other
OO shared libs
      
h2pas is not bad, but extension to h2pas that digs further????? Extension
and inclusion would not seem like a bad idea to me.
      
I've taken my self two months to test kylix, tested delphi my whole bussines
life. But there are details that make freepascal and lazarus go beyond limitations
of proprietary software. 
      
As for one of your previous comments. Yes, wine functions are part of every
software you produce, only the smallest software would allow to avoid wine.
As for delphi, the god damn m...f... is not portable CLX is not enough to
make a sandwich, about serious coding you always end up with platform dependent
functions (no way to avoid).
      
Preprocessor of that kind would need.
Parser of gcc configuration
Being able to go dig in subunit.
Eventually even avoid macro's, they're not vital as you see where I'm pointing.
Being able to make abstraction unit that calls lib functions. 
<#include somelibrary.h> changes to somelibrary.pas in some way that
we'd agree on, and job's done, interface is correct and source had to change
the smallest way.
      
      
      
      
But as it concerns wrappers, I guess everyone has agreed that is a good idea.
I'll make my API freeze, and start making changes. Lower objects I'll just
update with changes and comment changes a lot, upper I'll make some class
extension to be clearly what's added. Then after, if you'd approve change
you'd have easyer implementing in CVS.
      20020308104631.5c61c60b.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
        
        
matjaz