h at ordia.com.ar
h at ordia.com.ar
Sat Oct 11 09:21:56 PDT 2008
On 10/2/08, Hernán Ordiales <h at ordia.com.ar> wrote:
> On Thu, Oct 2, 2008 at 10:19 AM, David García Garzón
> <dgarcia at iua.upf.edu> wrote:
>> Must to say that i didnt even tried to compile pyclam it but i would like
>> do two suggestions that i don't even know whether they are feasible or
>> The first one is to move clam/CLAM/pyclam to clam/pyclam (or maybe PyCLAM
>> PyClam), this is because when building debian packages we could consider
>> it a
>> different source package not mixing c++ build with python module build. Is
>> feasible? do you all agree with the change?
> Yes, it is feasible since the build scripts looks for clam headers at
> 'prefix' location, in the same way than clam based apps.
> I put it under CLAM directory because is intrinsically related with
> the clam library, but i have no objections to the proposed move.
I should move it to the root path? I like pyCLAM too
>> The second one is about the build system. Taking a light look at the
>> SConstruct file i see several harcoded CLAM defines. Such options as
>> in clam should be available from the pkg-config files installed with clam.
>> might even use the clam scons tool the way we use it from the
>> sconstruct. The scons tool should use the pkg-config options. Any reason
>> not doing it like that?
> No, there is no reason :-D. Just that I was eager to see the bindings
> working and i was unsure of how pkg-config works under scons and
> neither knew how to use clam scons tools.
Done (commit r12147).
Next step is making it crossplatform and installable (at the moment
only generates the clam.so in the same dir)
> I'll take this thread to notify the list of some recent changes to the
> * I reduced the amount of wrappers and workarounds, so the python code
> now looks even simpler and more clean.
> ** I managed to get the bindings working of some classes that were not
> working with the semi automatic binding generation/parser. The
> solution is do it by hand. The cons of this is some of them are not
> fully exposed, some just have a couple of methods available.
> ** I found a way to have DataArrays working in python as vectors, in
> other words use the setter and getter by index through [ ]
> * Unit tests using pyunit.
> * Py++ doxygen documentation extractor script added, fixed and
> improved. Now most doxygen documentation is accessible from python
> through the help() command or documentation string at .__doc__ member.
> * Split of the python library in many files in order to get a lower
> compile time. Before was only a single file, useful to have the
> generated bindings ready to be compiled updated in the server, but
> when the library gets stable, automatic generated files could be also
> uploaded to achieve the same.
> * License inclusion in bindings files generated by py++.
>> Clam-devel mailing list
>> Clam-devel at llistes.projectes.lafarga.org
> GnuPG: 0xEE8A3FE9
More information about the clam-devel