[OPEN-ILS-DEV] oils_utils.h et alia

[Scott McKellar]

--- Bill Erickson <erickson at esilibrary.com> wrote:

> Mike Rylander wrote:
> > On Nov 14, 2007 12:00 AM, Scott McKellar <mck9 at swbell.net> wrote:
> >   
> >> Where is oils_utils.h supposed to reside?  ...and where or what is
> >> the openils directory?
> >>
> >> In ils/trunk/ the only file by named oils_utils.h is in
> >> Open-ILS/src/c-apps/, where also reside four .c files that
> #include it.
> >>
> >> However the file Open-ILS/src/extras/oils_requestor.c #includes
> >> "openils/oils_utils.h".  I see no directory named "openils" in the
> >> repository trunk.
> >>
> >> Elsewhere I see references to other header files in this
> non-existent
> >> directory: idl_fieldmapper.h, fieldmapper_lookup.h, and
> oils_event.h.
> >> Of these, two are in the c-apps directory and another is in the
> >> apachemods directory.
> >>
> >> What's up with that?  Unless you have some funky links that aren't
> >> reflected in the repository, I don't see how some of these files
> >> can even compile.
> >>
> >>     
> >
> > These are moved into a single temp dir by the build process and (by
> > default, during the build) live in trunk/ILS/.tmp/
> >
> > My understanding of Bill's purpose there was to keep everything in
> one
> > place at build time to reduce confusion back when a whole lot more
> was
> > being built in the ILS tree -- back when OpenSRF and Evergreen were
> in
> > one repo.
> >   
> 
> I think awkward evolution defines it a little better.  In my opinion,
> 
> the ILS C headers need the same treatment the OpenSRF headers
> received 
> when OpenSRF was given its own repository.  Any shared headers should
> go 
> into a new Open-ILS/include/openils/ directory, 
> -Ipath/to/Open-ILS/include should be appended to CFLAGS for the
> various 
> makefiles, and all C files should #include the fully qualified 
> <openils/some_header.h>.
> 
> Thoughts?
> 
> -bill

I agree.  Except where there is some persuasive reason to the 
contrary, the directory structure within the repository should 
reflect the directory structure of the build environment.  That way 
you don't need to understand the build in order to understand the 
code.

That said, I can live with it either way.  What I don't like is
having different files #include the same header in different ways:

    #include "oils_utils.h"
    #include "openils/oils_utils.h"

There is some virtue in consistency.

Scott McKellar
http://home.swbell.net/mck9/ct/