RFC: libverto nearing release

[Ezra Peisach]

On an integration front you should use AM_INIT_AUTOMAKE with the 
automake version you require. AM_SILENT_RULES was not introduced until I 
believe 1.11...  If I create a dist on a newer machine - it compiles on 
centos 5 - and passes tests - but that has automake 1.9.6.... and cannot 
generate configure scripts.

Also - your .pc files will not work - you substitute prefix, but libdir 
get defined in terms on exec_prefix - so that should be added.

The build tests will not work without shared libraries.  The abi test - 
which should work on a static lib - fails - as you are looking for the 
.so shared library.  In addition  objdump is not universal. nm might be 
more appropriate - as I believe all unix type platforms have it (I might 
be wrong here)

Your configure script says LIBRARIES TO BE BUILT with "yes" next to 
them. Those that do not should say "no" - currently blank. (configure 
invoked with no arguments)



The timeout test fails on fedora 14 - i386: module glib - time is out of 
bounds - but this is glib < 2.29 - the test should say not supported...

  I can provide patches next week when I am back in town for some of 
these....

Ezra






On 6/30/2011 4:12 PM, Simo Sorce wrote:
> On Thu, 2011-06-30 at 15:25 -0400, Greg Hudson wrote:
>> On Thu, 2011-06-30 at 11:31 -0400, Nathaniel McCallum wrote:
>>> The purpose of this email is to let everyone know that libverto is
>>> nearing its first release (hopefully today) and I would like to request
>>> feedback. The project is hosted here: https://fedorahosted.org/libverto/
>> Here are a few things I flagged, mostly cosmetic.
>>
>> 1. I couldn't find the git repository from the web site.
> I added a link to the main page, here you can find all the git URLs
> supported:
> http://git.fedorahosted.org/git/?p=libverto.git
>
>> 2. We would prefer not to see camel-case in the type names, as some of
>> them will appear in our function signatures.
>>
>> 3. We would prefer typedefs for the types in order to reduce the amount
>> of horizontal space it takes to add an event context to a function
>> signature.  I have a personal preference for typedeffing the pointer
>> type for abstract types, so that to the caller it doesn't look like a
>> dereferenceable object.
> Sorry Greg but this is my fault, I asked Nathaniel not to typedef stuff
> because I personally find it hinders readability, for API users,
> especially for pointers.
> It doesn't matter if it looks dereferenceable to the caller when it is
> opaque and therefore you have nothing to dereference, but it tells you
> that this is a pointer and not a structure, making APIs more clear on
> what they expect from you.
> I find particularly annoying when APIs define then mix typedefs to
> pointer and non-pointer to the same underlying type, it gives a level of
> uncertainty we should really avoid in security related products IMO.
>
>> 4. The documentation of verto_new(NULL) exposes more of the
>> implementation than I think is really wise; in particular, promising to
>> try to figure out what event libraries you're linked to seems
>> over-generous.
> It's necessary, you want to use an event library the calling application
> is already linked to by default.
>
>>> There are a few known issues. The most important is that libverto has
>>> only been tested on Fedora and there will likely be some (hopefully only
>>> minor) issues on other platforms.
>> When (1) is addressed, I will test the build on Solaris 10.
> See above,
> Simo.
>