On 27/07/12 06:59, Dave Reisner wrote:
On Thu, Jul 26, 2012 at 03:51:20PM -0500, Dan McGee wrote:
On Thu, Jul 26, 2012 at 3:23 PM, Paul Barbu Gheorghe <barbu.paul.gheorghe@gmail.com> wrote:
Signed-off-by: Barbu Paul - Gheorghe <barbu.paul.gheorghe@gmail.com> --- lib/libalpm/alpm_list.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/lib/libalpm/alpm_list.c b/lib/libalpm/alpm_list.c index 39eded1..b9e7cba 100644 --- a/lib/libalpm/alpm_list.c +++ b/lib/libalpm/alpm_list.c @@ -21,13 +21,11 @@ #include <stdlib.h> #include <string.h> +#include "util.h" + /* libalpm */ #include "alpm_list.h" -/* check exported library symbols with: nm -C -D <lib> */ -#define SYMEXPORT __attribute__((visibility("default"))) -#define SYMHIDDEN __attribute__((visibility("internal"))) -
The reasoning behind this is alpm_list.c/h is a completely standalone set of files, so we don't link back to anything in the rest of alpm. With that said, the duplicates were quite on purpose and I'm not inclined to apply this patch.
-Dan
Hmmm, so this is totally non-obvious looking at the code and at history. Why do we care about keeping alpm_list as an island? It's not treated any differently in the buildsystem, and both alpm.h and alpm_list.h expose symbols in a singular shared object.
If we aren't going to merge this, we should at least document the duplication.
I believe the idea was to be able to just use alpm_list.{h,c} in another project without linking to libalpm. Personally, I see no need to keep that separation. There are more general list implementations widely available and I have never seen another project use this. Allan