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