Hello Andreas!
It is great that you are working with this...
Are you considering having options to choose from on how to do the import?
Then we could add options as new ways are implemented. I can think of the
following alternatives from your example and explanation below:
O Import plain C++ (source and header files).
[ ] Reorder imports, offer to add header file to imports.
[ ] Use existing model elements as types and features in the import.
O Preprocess using ArgoUML-builtin preprocessor.
O Preprocess using Makefile %.E target.
/Linus
2008/6/3, "Andreas Rückert" <[EMAIL PROTECTED]>:
>
> Hi!
>
> -------- Original-Nachricht --------
> > Datum: Mon, 2 Jun 2008 22:04:41 +0200
> > Von: "Linus Tolke" <[EMAIL PROTECTED]>
> > An: [email protected]
> > Betreff: Re: [argouml-dev] C++ module preprocessor
>
> > Hello Andreas!
> >
> > When first reading this my immediate feeling was that this goes directly
> > to the purpose of the reverse engineering.
>
> Well, since it started with a request from Jan (I'd like to see this as
> some sort of
> 'user-centric' development), it's quite natural that there's a purpose
> behind the
> feature... :-)
>
> > I can think of examples where I'd prefer to reverse engineer the code
> > before
> > the preprocessor.
>
> Yeah, but it many cases, it'll fail...Jan came up with this problem...
> test.h:
> =======
> class myClass {
> ...
> }
> =======
>
> test.cpp:
> =======
> #include "test.h" <-- this include is ignored, so the definition of
> myClass is unknown
>
> main() {
> myClass *myVar; <-- breaks import, since myClass is not a known type,
> which
> ... causes a parser exception.
> }
> =======
>
> > On the other hand, I can understand that you will also want to reverse
> > engineer the code as processed by the preprocessor. In that case I think
> > that the first option is the best. An effort must be made to run the
> > preprocesser exactly as run when building the code. Is there a makefile,
> > or
> > Makefile specifying the compiler, settings, include directory paths? If
> > the
> > build is normally done from Visual Studio, how do we get these paths from
> > within that environment? There are plenty of questions to be answered.
>
> Yeah, but parsing complex Makefiles can be a real pita. And if there are
> a bazillion vars defining include directories (maybe depending on the
> current
> architecture of the machine), compiler switches etc, reproducing this exact
> configuration is almost impossible.
>
> Jan just mentioned, that some default libs have compiler-specific keywords,
> that might cause big problems, too.
>
> Ciao,
> Andreas
>
> --
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
