wxport from cvs
Pablo d'Angelo
pablo.dangelo at web.de
Fri May 16 15:04:59 BST 2003
Hallo Kai-Uwe!
Kai-Uwe Behrmann schrieb am Freitag, den 16. Mai 2003:
> Am 16.05.03, 10:47 +0300 schrieb Juha Helminen:
> Hi Juha,
>
> > Hi,
> >
> > Finally I downloaded wxport from cvs. I do not like tortoiseCVS as it
> > makes zombie processes in Win98 (might be some setting errors??). At
> > least it can make checkouts from sourceforge.net.
> >
> > BCB do not manage to compile
> > extern "C" {
> > #include <pano12/filter.h>
> > }
> Yes and for gcc I need it to make the stuff visible. I tould an author of
> an C++ toutorial, he could not imagine what is going on. Otherwise I found
> an other toutorial in which the author wrote about this "extern" step.
It is needed when linking objects compiled with gcc (c compiler) and
g++ (c++ compiler), because they use different name mangling.
This will tell the c++ compiler to use c style name mangling for the
references to the functions in filter.h
bcb should be able to compile that. whats the error you get?
> > Would it be good idea to copy filter.h, panorama.h and version.h to cvs
> > as then everyone has correct files? Library is needed but it need not to
> > be included as BCB uses implib -program to make it from DLL.
> Yes do so.
I don't think this is a clean solution. we should use the libpano
tool lib that is installed on the current system, because the depend
on eachother. What does the implib program do? generate headers from
a .dll?
> On the other side I think about classifying all structs from libpano.
> It seems difficult to build the C++ wrapper for the lib, because there is
> no clear well defined interface for libpano. All we do is sharing some
> structs putting therein everything and give it libpano for some steps to
> work later again on it. Building C++ wrapper for libpano would need some
> serious time to solve. --- other opinions / hints how to do this?
It depends how much functionality we need from libpano. The model
classes in hugin can be seen as data model for libpano. (well probably
not a really good one yet, but its on the right path I think).
Then some other classes or member functions could work on that model
(for example optimizing some variables etc.) I would only write these
wrapper classes incrementally, when I need the functionality.
It would be nice to have a nicely abstracted object oriented interface
to the whole PT functionaly, but doing that will get us distracted from our
real goal, I think.
> Pablo goes the elegant way - as far as I understood , puts he everything
> in xml style and uses only from libpano what he needs -- am I correct so?
hugin is only using PTOptimizer(.exe) and PTStitcher(.exe), it does not
even include/link to libpano. communication goes through files instead of
function calls.
But some time in the future I might need some functionality from
libpano, like partial undistortion of images.
ciao
Pablo
--
http://wurm.wohnheim.uni-ulm.de/~redman/
Please use PGP
More information about the ptX
mailing list