Patrice Dumas <[EMAIL PROTECTED]> writes: >> projects. I still think either a Lesser GNULib project is needed, or >> that gnulib modules could become parametrized, or that gnulib could >> contain multiple implementations of the same interface (with different >> characteristics, license-wise, thread-safety, malloc use, etc...). > > It seems to me that it is allready possible. If a module has another name > it could have different characteristics. If I'm not wrong the alloca and > alloca-opt have allready that kind of relationship, and also xalloc and > xalloc-die for example. Maybe you want the similar things but within just one > module with conditionnals?
I guess separating two implementations of the same interface by having two different modules would be fine. However, I don't think neither alloca{,-opt} nor xalloc{,-die} are good examples, they don't implement the same interfaces. There is a potential problem with this approach though. Consider if the module is large, e.g. argp. It would be good to have a version of the argp module without the unlocked-io dependency (I know that specific problem is discussed in other threads, but let's use this as an example). First, there is the file name collision of files. Some files may be shared between the modules, but some will differ. Secondly, if the code is separated into different files, they would likely have to be kept in sync. The bigger the differences, the harder it is to keep both versions working properly. Consider a thread-safe getline implementation, the one in gnulib differ substantially from the glibc one, and when I needed a LGPL getline, I wrote a gnulib module for it based on the glibc code. Adding that module to gnulib would mean two getline code bases to maintain. So I think it would be better to parametrize one single implementation to avoid those problems. Perhaps it can be decided on a case-by-case basis which approach is better, though. >> I found it helped to attack the problem one module at a time, >> carefully considering the details. Exactly which modules do you need >> which are under the GPL in gnulib today? > > alloca malloc realloc strtod atexit dup2 getcwd getpagesize memmove memset > strerror regex Of those, only getcwd is GPL; the others are LGPL or public domain. There is a LGPL getcwd in GLIBC, perhaps you can use it instead. Regards, Simon _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib