[vsipl++] [patch] Building VSIPL++ shared libraries

[Jules Bergmann]

Stefan,

Thanks for the feedback!  I've incorporated your suggestions.

			-- Jules


> Jules, overall this looks fine. I have one high-level question (at the 
> end), as well as a couple of specific comments / questions.


>>  define link_app
>>  @echo linking $@
>>  $(CXX) $(LDFLAGS) $(call dir_var,$(dir $<),LDFLAGS) -o $@ $^ \
>> -  -Llib -lsvpp $(call dir_var,$(dir $<),LIBS) $(LIBS)
>> +  $(call dir_var,$(dir $<),LIBS) $(LIBS)
>>  endef
> 
> Where does the link command get -lsvpp from after this change ?

Users of the rule include $(libs) in the dependencies, so it gets picked 
up in $^.

> 
>>  hdr    += $(patsubst $(srcdir)/src/%, %, \
>> -             $(wildcard $(srcdir)/src/vsip/opt/cuda/*.hpp))
>> -hdr    += $(patsubst $(srcdir)/src/%, %, \
>>               $(wildcard $(srcdir)/src/vsip/opt/diag/*.hpp))
>>  
> 
> After you take cuda out of $hdr, would dependency generation still work 
> with CUDA enabled ? (It looks like instead of removing the above, we 
> should decorate it with
> 
> #ifdef SOME_CUDA_VARIABLE
> ...
> #endif
> 
> no ?

Oops, this removal wasn't intentional.  Let me double-check how that 
happened.

> 
>> +ifdef BUILD_SHARED_LIB
>> +libs += lib/libsvpp.so
>> +lib_svpp := lib/libsvpp.so
>> +else
>> +lib_svpp := lib/libsvpp.$(LIBEXT)
>> +endif
> 
> This raises an interesting question: Are we ever going to ship a 
> DSO-only build variant ? With DSOs enabled, I would expect us to provide 
> both, libsvpp.a, as well as libsvpp.so.
> (Note that this makes compilation slightly more complex, as then we have 
> to build two sets of objects, one with -fPIC and one without. But the 
> alternative, adding more build variants, sounds even worse, as far as 
> build times and memory footprints are concerned.

Right, we definitely want to avoid more variants!

This change still builds (and installs) both libsvpp.so and .a. 
However, it uses -fPIC code for both (arguably lowering performance). 
However, a quick & dirty BM of SSAR didn't show a noticable difference.

Like version numbers, if we package this, let's revisit building both 
fPIC and non-fPIC code.

				-- Jules

-- 
Jules Bergmann
CodeSourcery
jules at codesourcery.com
(650) 331-3385 x705