Re: [Chromium-dev] IB support changes

[Robert E. <pa...@tu...>]

Hi, Mike -

> I see you've updated the IB stuff, at least the makefiles, to use the 
> TopSpin stack.  

Yup, only the Makefiles (and one bad header declaration).  I intended the change 
to be completely transparent to those who don't build IB (which I think must be 
nearly all, as the bad header declaration would have stopped any main trunk 
compilation of the IB support), negligible to all builders who don't have the 
TopSpin stack, and essential to those that do.

> This is a really bad idea.  You'll want to run the 
> OpenIB gen1 stack or better yet the Mellanox HPC Gold stack which is 
> public and "easy" to use.

I'll defer to your IB expertise, as I'm not nearly as familiar with all the 
issues regarding competing stacks.

In this particular instance, I was constrained to this particular stack; so 
other issues didn't enter the decision.

On a related note, I was somewhat uncomfortable checking in Makefile changes, 
even as minor as this, to the public source, even though there are a few other 
examples of private or semi-private changes that snuck in here or here, that 
don't affect other folks...

What's the right way to do this?  Put them in as I did, allowing only extensions 
of the INCLUDE_DIRS and LDFLAGS variables so that users without the 
subdirectories won't be affected?  Define a new variable to protect it from 
anyone who doesn't explicitly set the chosen variable?  Don't do it at all (and 
maybe clean up the examples that are already there)?

It may be nice to define some directory outside of the Chromium tree where 
custom files can be put (for commonly customized things like cr/options.mk, and 
maybe even custom SPU directories) to avoid both losing track of necessary local 
changes during a clean check-out, and to avoid accidentally commiting a local 
change to the repository... but I'm not sure the added utility would be worth 
the complexity required.

Thanks for your insights,

Bob Ellison
Tungsten Graphics, Inc.