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

Bill Erickson erickson at esilibrary.com
Wed Nov 14 14:22:35 EST 2007


Dan Scott wrote:
> On 14/11/2007, Scott McKellar <mck9 at swbell.net> wrote:
>   
>> --- 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.
>>     
>
> +1 for #include "openils/oils_utils.h"
>
> (To put my money where my mouth is, I'm also willing to rework the
> build accordingly)
>   
Dan++


-- 
Bill Erickson
| VP, Software Development & Integration
| Equinox Software, Inc. / The Evergreen Experts
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com



More information about the Open-ils-dev mailing list