Re: IB support changes

>
> 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...

This probably doesn't matter a lot right now as there are only a few 
Chromium IB users and the IB stacks are still more painful to deal with 
in terms of userspace code than they should be, that a few added steps 
isn't much to deal with.  My main concern is that it's going to be hard 
to deal with bug reports and layer issues unless we are all on the same 
stack.

>
> 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)?

This is why you have to enable IB support to get it compiled in, much 
like the other network layers.  This is probably the best route, but we 
might want to move the definitions of INCLUDE_DIRS and LDFLAGS for IB 
support to options.mk as IB_INCLUDE_DIRS and IB_LDFLAGS so that a user 
knows if they want IB support that they need to modify the IB_SUPPORT 
flag as well as the paths.

>
>
> 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.

This is always tricky.  I ran into this while doing Raptor.  To build 
Raptor, it has to be in the Chromium tree (cr/progs/raptor).  I just 
kept a separate CVS repository for this in my tree and 'cvs update' 
would do the right thing.  I'm not sure what the best thing is on 
modifying central parts of Chromium for private work.  I would suggest 
branching the tree, but of course then you have sync issues against the 
truck to contend with...  In the end, I'm not sure there is a good answer.

Having a known custom directory that overrides defaults, like 
options.mk, might not be a bad idea.  Custom SPUs are probably better 
done with CVS within CVS like Raptor was done.

Just my 2 cents.  I struggle with this regularly myself.

-Mike


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click