Using libuuid for guid generation (was: WARN <qof.engine> [guid_init()] only got xxxx bytes)

[Christian Stimming]

Am Dienstag, 8. März 2011 schrieb John Ralls:
> >> My proposal would be to keep the code as-is (if it aint
> >> broke, dont fix it) on all platforms except Windows -- where it truly is
> >> broken.  On Windows, sure, change it to the Win32 API, but why rip out
> >> working code elsewhere?  (Especially since we need to keep the code
> >> around for other platforms anyways).
> > 
> > Why change ? I would change this to keep the code easier to maintain.
> > Other guys have specialised in creating good uuid's. We are only
> > consumers of uuid's.
> > 
> > By the way other larger projects rely on libuuid as well like for
> > example: apache (verified both on solaris and linux).
> 
> It's part of libc on BSD. The include directive will be a little different,
> <uuid.h> instead of <uuid/uuid.h>. Interestingly, it's also in libc on
> OSX, but the header is Ted Ts'o's (of Linux fame) and it's at
> <uuid/uuid.h>. That means that we wouldn't need to use the CoreFoundation
> interface, which is nice.
> 
> On Debian, the header is in a separate, not-installed-by-default, package,
> uuid-dev, so configure will need to make sure it's there. That's probably
> true on most distributions.

Thanks for the additional research. To me, this confirms clearly enough we can 
rely on libuuid being available for the job we want to use. On windows, it 
will surely solve a currently existing problem; on Linux/Unix, it is probably 
as good as our existing custom code. Yet again, using the same solution on all 
platforms is clearly advantageous because this way, the single common 
implementation is ensured to be tested by us when we use gnucash on Linux.

If you ask me, I say you can go ahead right now and replace the qof/guid.c 
implementation by some api calls to libuuid. Thanks a lot!

Best Regards,

Christian