[openib-general] RE: OpenSM Work

[Eitan Zahavi]

Hi Hal,

Regarding the directory structure of OpenSM:
>From the developer standpoint it makes life easier to have the H files
located on the same directory the C file is located. I still use "grep" a
lot.

I could not find even one GNU stile project that uses a separate include
directory for H files during the development phase (all of them eventually
install H files into $prefix/include).

Please see the short list of projects below as a reference but actually I
picked them randomly from the FSF GNU projects page. 
Tcl 
Expat
Enscript
Gimp

So I guess this methodology of keeping all H files in a separate directory
is more a "kernel" convention?
What are the implications of moving the H files each into its sources dir?

This issue is more a style and adherence to the standard coding practices
for user level code then something that prevents us from progressing.
However I wonder what are the strong reasons for keeping it the way it is?

EZ
Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL


> -----Original Message-----
> From: Hal Rosenstock [mailto:halr at voltaire.com]
> Sent: Friday, August 05, 2005 7:24 PM
> To: Eitan Zahavi
> Cc: 'Matt Leininger'; openib-general at openib.org
> Subject: RE: [openib-general] RE: OpenSM Work
> 
> Hi Eitan,
> 
> While I don't understand why the update for 1.8.0 can't be done by
> patches which is the usual way (I think it could be broken at least into
> complib, then vendor lib, then SM, and finally SA changes), I will work
> on merging Yael's branch for this. Note that there may be some back and
> forth on this similar to comments on patches. In the future, I hope that
> work can be done in smaller incremental pieces and with patches.
> 
> As to the directory structure, there are projects which follow the
> structure which is being used in the OpenIB tree. The makefiles already
> do install the headers. That being said the directory structure is not
> cast in stone but there is a lot of churn here to change it. Are there
> any other clear benefits ? Does it somehow make your internal
> development easier ? If that is it, I don't see why a correspondence
> script wouldn't work. Typically things like this are community decided.
> 
> I would think the simulator work is separable and would prefer to hold
> off on this until the OpenSM merge is done and working. That alone seems
> like a lot to swallow at once.
> 
> Finally, as to feedback on the proposals for OpenSM work, as I recall,
> there were responses from both Tom and myself both being supportive of
> new functionality and some design review issues (particularly relating
> to routing algorithms proposed). I would expect this work to generate
> more feedback as there is code to go along with it or possibly even with
> an update on the design approach.
> 
> -- Hal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050807/b50b31e8/attachment.html>