Andreas Rückert wrote:
(...)
I'll send you the module in a p-mail.
Hi,
it is very hard to review your changes since the module sources you have
sent me are pre-revision 210 - when the whole repository was recovered.
Please update your sources from the repository or tell me explicitly
which files were changed by you and I will look specifically at those.
Thanks in advance and regards,
Luis
PS: I'll proceed with the assumption that only the following files were
changed:
argouml-cpp/build.xml
argouml-cpp/src/org/argouml/language/cpp/reveng/CppImport.java
Added argouml-cpp/lib/anarres-cpp.jar
Some more changes in argouml/src/argouml-build and
argouml/src/argouml-app that I won't review since these will be done in
a different way...
Concerning jcpp integration into ArgoUML I think it should be possible
for modules to declare additional jars that must be loaded or, if it
isn't we should create an issue for the ArgoUML module loader to support
it.
That's what I tried. Declared the jcpp jar in the module's manifest, but since
there isn't even a ext/lib directory, or so, and all the other jars are in the
lib
dir, it's very likely, that this feature is simply not implemented in Argo.
As Tom stated we need to include anarres-cpp.jar in the argo-cpp jar.
This means that the Ant's jar target must be changed to include copying
the anarres-cpp.jar from argouml-cpp/lib/ into argouml-cpp/build/lib/
and the argouml-cpp/src/org/manifest.mf must include lib/anarres-cpp.jar
in the "Class-Path" entry.
Or should I create an attachment to issue 2947, or so?
I think a branch of argouml-cpp is the ideal way to proceed for now in
things related to the preprocessor new development since we're
approaching 0.26. But, anything that is necessary in the existing reveng
code could go directly to trunk - the reveng is still pre-alpha and
mainly the result of a spike, so any improvements coming from your work
or needs related to it are welcome.
In my view, the current RE simply doesn't work for most existing projects.
Almost anyone declares the classes in the header files, and since the include
statements are ignored, but the parser requires to know every type in the cpp
file, RE of any real-world app will fail. So (in my eyes), the current code is
not
really worth to be preserved for the 0.26 release. (...)
In my view, the existing RE with the preprocessor will simply fail to
work with most existing C++ projects. It will simply remove one - the
first - of the limitations of the following list (available in CppImport):
+ "preprocessed files only, i.e., works on full translation
units;"
+ "very few C++ constructs are supported, e.g., enums,
unions, templates, etc, aren't;"
+ "no support for non-member variables and functions;"
+ "no integration with the C++ generator => RTE won't work!;"
+ "no operator overload support;"
+ "very immature, certainly this list needs to grow!";
But, I think that the current code and probably the code with the
preprocessor integrated will be worth including in the 0.26 release.
Mostly as a pre-alpha show-off of what we are doing already to recruit
developers to help removing more limitations from that list ;-).
(...)
Let me just send you the module at this point, ok? Check it, and I think it
should
go into the trunk. We should add GUI stuff for the include directories and c++
RE should be a lot better. That's why I'd like to see it in 0.26.
Given the changes being minor I would agree. I'm a bit afraid that the
changes concerning GUI will delay 0.26, but, this is argouml-core and if
it is squeezed there I'm also in favor of extending argouml-cpp to take
advantage of it.
Ciao,
Andreas
Regards,
Luis
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
