Re: [Opencxx-users] Code reorganization, Win32 compiler

[Marc O. i L. <mar...@tr...>]

Grzegorz Jakacki wrote:

>Hi Marc,
>
>Thanks much for your contribution. I fully agree with your point of view
>about separation of driver from the rest of the code.
>
>This is not the way to go on Windows however, since as I understand the
>requirement is that occ runs at compiles under vanila VC++ with no bash
>etc.
>
>  
>
In Visual Studio, there is no easy way of launching a C++ file with a 
different preprocessor, as all the executables are rolled into one, and 
even then, VS just loads the C compiler as a DLL using COM. A real mess...

>One solution i have been thinking of was translating the script into C
>with a tool (sh2c), but I am not sure if details really work out.
>
>Another solution is the one that you are proposig.
>
>The main problem however is that nobody is currently maintaining OpenC++
>on Windows. Windows is very different that oter unix-like systems---for
>many platforms we can build and test on CompileFarm, unfortunately not for
>VC++.
>
>To wrap it up, I cannot reliably apply your patch, because I cannot
>reliably test the code afterwards. Would you find time to apply the patch
>and test yourself? Testing may require installing cygwin (bash).
>  
>
I tried it under cygwin and with SUSE 8.2, which is what we have on our 
internal server. I got the same results as with the CVS version, which 
is... None at all. In Suse both versions (mine and CVS) build, but fail 
to compile anything as the parser chokes on a system header. Using -n 
works, though, and correctly translates the code. In Cygwin neither can 
load any library due to problems with libtool (i even tried to 
re-libtoolize it, as per an older message in this list, to no avail). As 
I don't have any idea on how autoconf/automake works (I just know that 
it's immensely difficult to understand, with all those m4 macros all 
over the place :), I can't really change the build scripts.

But I think you can just apply my patch and check that it works exactly 
as the version in CVS right now. My patch was just a proposal on how a 
small change could be the first step into separating OpenC++ into a 
library and different drivers for different needs, keeping 'occ' as the 
gcc-substitute on Unix systems. In fact the changes are very small:

1. Remove parser depency on global variable wcharSupport, which is now 
passed as an argument to the Parser contructor.
2. Put QuoteClass code in quote-class.cc. It was in metaclass.cc before, 
I don't really know why.
3. Set all the dloader #defines in metaclass.h, because it's the 
metaclass code that defines how metaclasses are created, and therefore, 
loaded.
4. Change the Walker so that it does not depend on a particular 
metaclass implementation. When it needs a metaclass, it just calls the 
driver-exported LoadMetaclass function.

Think about this: You don't want to build a code transformer, but just a 
small app that counts how many times a member function is called. So you 
really don't need all that metaclass-compile code, and certainly not the 
part were occ tries to behave like a compiler driver (calling the 
preprocessor, then transform, then compiler, etc.). So you develop a 
small app that just registers a metaclass, calls the OpenC++ lib and 
writes the results.

The important point to notice is that the core code does not depend at 
all on Opencxx::Metaclass. As long as there is some way of signaling 
that a 'Opencxx::Class'-derived class is needed to translate a 
particular class, the parser and the walker work perfectly. 
Opencxx::Metaclass is just one way of designing metaclasses (using 
DLLs), but others could be designed. In fact it's easy to build a driver 
that does not depend at all on Opencxx::Metaclass, and has it's own 
metaclasses compiled in. Of course it needs to touch 
opcxx_ListOfMetaclass, which is clearly an ugly hack.

The solution, I think, is to make the whole Class loading/registry 
protocol public. We'd have a library with two public interfaces, one for 
drivers and another for metaclass builders. I call these interfaces 
'opencxx.h' and 'mop.h', respectively. In 'opencxx.h' we'd have:

- Access to buffer.h, for loading source files.
- Access to Lexer, Parser and Walker.
- The definition of a Class registry (now implemented using 
opcxx_ListOfMetaclasses), which the driver would have to subclass and 
pass to the Walker (and probably the parser too). This class would have 
functions for loading/creating Class-derived classes (be it from DLLs or 
anything else) and for creating new instances for those. Or maybe we 
could integrate those functions in Opencxx::Class, but that would 
require that all drivers subclass Opencxx::Class, an dI don't know which 
system is worse.

'mop.h' would be the interface for building those OpenCxx::Class derived 
classes, and it would include all the functionality in there right now 
except the opcxx_ListOfMetaclasses stuff.

The exact protocol on loading/creating metaclasses, that is, everything 
that is right now in metaclass.cc would not be in the library, as it's 
really a driver-dependent thing. Of course, the 'occ' driver that just 
camouflages itself as a standard C++ compiler could continue using that 
way of creating/loading Classes, using libtool, etc. But any other 
driver can do it another way. Right now, as we use TCL to drive our 
build system, I'm tempted of implementing a TCL-based driver, but I 
still don't know how difficult that would be.

> Will you
>be interested in maintaining the VC++ build afterwards?
>  
>
I am currently working in a very large project (game development), and 
I'm pushing really hard for using OpenC++ to make it easier to control 
the run-time part of the engine (that is, intefacing the C++ classes to 
scripted events, etc.). I'm not sure yet on whether we'll be using it, 
it all depends on how can I integrate it with our current tools (which 
are, unfortunately, based on MS Windows).

I'm now going to implement all the changes I have described, trying to 
keep the 'occ' driver working on SuSE. In fact, it's just a refactoring. 
The only thing I won't have time for is dealing with autoconf. So, if 
it's OK with you all, I'll publish those changes and then you can decide 
what to do with them.

Sorry if I've been a little verbose, but I'm really interested in using 
OpenC++ in our project, which will not be possible if we don't make it a 
little more flexible.

Best regards and thanks for listening,

Marc Ordinas i Llopis

>Best regards
>Grzegorz
>
>On Fri, 7 Nov 2003, Marc Ordinas i Llopis wrote:
>
>  
>
>>Alexandre Tolmos wrote:
>>
>>    
>>
>>>Hi Marc,
>>>
>>>There is already a driver for Win32 called "driver2.cpp" in "src" but
>>>I  don't know if it's up to date and suitable for VS.NET.
>>>
>>>      
>>>
>>No, it's not up to date, unfortunately.
>>
>>    
>>
>>>Btw, which version of OpenC++ did you use ? I commited a patch on the
>>>1st of November which completes the MacOS X port and upgrades the
>>>garbage collector to version 6.3alpha2. I recommend you to upgrade to
>>>the latest HEAD revision.
>>>
>>>      
>>>
>>Yes, I'm aware of your patches, and I generated the patch with CVS.
>>
>>The point is that in Win32 you need to generate the DLLs for the
>>compile-time classes in a very different way from Unix. And in Visual
>>Studio you can't just tell it to call occ.exe instead of cl.exe (MS'
>>compiler). So you need a different Metaclass implementation and a
>>different driver. Fortunately, it's easy to separate concerns:
>>
>>The library
>>1) Parses C++.
>>2) Transforms it according to some metaclasses.
>>
>>And the driver
>>a) Provides a way of creating metaclasses.
>>b) Loads those and passes them to the library (when the library demands
>>them).
>>c) Offers some kind of interface to the outside, be it substituting the
>>usual call to the compiler, be it another different way.
>>
>>Of course, a and b can be independent, as long as there is a common
>>protocol. It's possible to create a driver that has all metaclasses
>>already compiled in, for example. Or the driver could use some scripting
>>language to implement the metaclasses.
>>
>>Anyway, I think patching driver2.cpp so that it works under Win32 is
>>wrong, what should be done is separating concerns and allowing an easier
>>way to create drivers. Of course, occ should be kept as the included
>>driver, because it works perfectly on Unix as a command-line substitute
>>of gcc.
>>
>>Regards,
>>
>>Marc Ordinas i Llopis
>>
>>    
>>
>>>Alex
>>>
>>>Le jeudi, 6 nov 2003, ? 16:42 Europe/Paris, Marc Ordinas i Llopis a
>>>?crit :
>>>
>>>      
>>>
>>>>Hi,
>>>>
>>>>We are going to use OpenC++ in a project, but we need to have a
>>>>working Win32 version. Creating a driver for use in VisualStudio.NET
>>>>is not easy, as the editor does not allow changing the compiler
>>>>executable. So I've had to separate OpenC++ in two parts, a library
>>>>and a driver. This requires very small modifications to the project,
>>>>and can be a step towards having a more modular code organization.
>>>>
>>>>I send you a patch (taken using cvs diff -u) with the required
>>>>changes, and I plan on having a Windows driver in short time.
>>>>
>>>>Regards,
>>>>
>>>>Marc Ordinas i Llopis
>>>>        
>>>>
>>>------------------------------------------------------------------------
>>>-
>>>Alexandre Tolmos
>>>E: ktulu at free.fr
>>>ICQ: 92964905
>>>------------------------------------------------------------------------
>>>-
>>>"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
>>>------------------------------------------------------------------------
>>>-
>>>      
>>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: SF.net Giveback Program.
>>Does SourceForge.net help you be more productive?  Does it
>>help you create better code?   SHARE THE LOVE, and help us help
>>YOU!  Click Here: http://sourceforge.net/donate/
>>_______________________________________________
>>Opencxx-users mailing list
>>Ope...@li...
>>https://lists.sourceforge.net/lists/listinfo/opencxx-users
>>
>>
>>    
>>
>
>##################################################################
># Grzegorz Jakacki                       Huada Electronic Design #
># Senior Engineer, CAD Dept.              1 Gaojiayuan, Chaoyang #
># tel. +86-10-64365577 x2074               Beijing 100015, China #
># Copyright (C) 2003 Grzegorz Jakacki, HED. All Rights Reserved. #
>##################################################################
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: ApacheCon 2003,
>16-19 November in Las Vegas. Learn firsthand the latest
>developments in Apache, PHP, Perl, XML, Java, MySQL,
>WebDAV, and more! http://www.apachecon.com/
>_______________________________________________
>Opencxx-users mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/opencxx-users
>  
>