Again, so sorry. On Wed, 28 Aug 2013 09:53:03 -0700 Andy Grover <agrover@xxxxxxxxxx> wrote: > On 08/28/2013 02:34 AM, Boaz Harrosh wrote: > > On 08/28/2013 07:59 AM, ronnie sahlberg wrote: > >> On Tue, Aug 27, 2013 at 3:56 PM, Andy Grover <agrover@xxxxxxxxxx> wrote: > >>> I think you may be able to avoid making bs.c into a shared library if you > >>> link tgtd with the -E linker option. > > > > Personally I prefer the .so option: > > > > For one I hate any double dependency, and specially an executable dependency. > > This is bad code design and a call for tons of problems. It is called the > > libraries hell. Each module should be self contained or only depend downwards > > on lower stack. library rules are exactly like package rules only depend > > downwards, and the complex dependency should be a tree never a graph ... > > > > Second with the bs.c as library it is clear and protected what are the API's > > the backends are to depend on and import, No crazy unexpected stuff from > > a loaded plugin. > > > > Please keep the second version as you sent it it is a much better style > > than the -E hack. > > You only get library hell when there are binary modules that expect to > run across different versions of the executable. I don't think that's > what we're talking about here. My initial request was to make it > possible for users to avoid installing dependencies for parts of tgt > they won't be using. That just requires tgtd and bs_rbd.so be separate > binaries, and tgtd work in the the absence of bs_rbd. Both binaries > would always still be generated from the same source version. > > So for me, linking tgtd with -E seems like the simplest solution to > reach that modest goal, but I'm fine with whatever Ronnie and Tomo do, > as long as it does the basic thing :-) Agreed, I prefer the approach, which looks like the simplest way to fix the problem we want to solve. I have no plan to support the complicated stuff like the different versions of the combination. I also don't think that others want to do so. -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
