[Clam-devel] pyclam

[h at ordia.com.ar]

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
>> to
>> do two suggestions that i don't even know whether they are feasible or
>> not.
>>
>> The first one is to move clam/CLAM/pyclam to clam/pyclam (or maybe PyCLAM
>> or
>> 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
>> it
>> 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
>> compiled
>> in clam should be available from the pkg-config files installed with clam.
>> We
>> might even use the clam scons tool the way we use it from the
>> applications
>> sconstruct. The scons tool should use the pkg-config options. Any reason
>> for
>> 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
> bindings:
>
> * 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++.
>
> cheers
>
>> David.
>>
>>
>>
>> _______________________________________________
>> Clam-devel mailing list
>> Clam-devel at llistes.projectes.lafarga.org
>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
>>
>
>
>
> --
> Hernán
> http://h.ordia.com.ar
> GnuPG: 0xEE8A3FE9
>


-- 
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9