Re: [SOSlib-devel] API reorganization[Scanned]

[Andrew F. <af...@ph...>]

Rainer

> But then odeModel.h itself needs to have the line
>=20
> #include "sbmlsolver/internal/odeModelInternal.h"
>=20
> to find this structure?
>=20

No.  This line only needs to be present in .c files and in other
*Internal.h files.

yours Andrew=20

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 12 June 2006 12:05
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: Re: [SOSlib-devel] API reorganization[Scanned]
>=20
>=20
> Andrew
>=20
> > I strongly suggest you create a new directory for=20
> 'internal' headers.
>=20
> Ok. I'll make another directory src/sbmlsolver/internal then.
>=20
> > ... External applications can then be built without the internal=20
> > header directory being on their include path.
>=20
> Ok, so in odeModel.h I have
>=20
>   typedef struct odeModel odeModel_t;
>=20
> But then odeModel.h itself needs to have the line
>=20
> #include "sbmlsolver/internal/odeModelInternal.h"
>=20
> to find this structure?
>=20
> Couldn't applications which include odeModel.h still have=20
> direct access to the the structure because they have the=20
> internal header file included via odeModel.h?
>=20
>=20
> > The internal headers could be called something like=20
> odeModelInternal.h=20
> > or odeModel_Internal.h
>=20
> So these internal header files can replace both=20
> odeModelStruct.h and odemodeldatatype.h, right?
>=20
> > Note you obviously don't have to declare structures and function=20
> > prototypes in headers.  They can be declared in .c files
>=20
> Most of our structures and many functions are used in several=20
> .c files, so these need internal header files if we want to=20
> avoid having to use the API functions internally, which could=20
> become quite painful.
>=20
>=20
> Rainer
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On Mon, 12 Jun 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > Sounds good
> >
> > I strongly suggest you create a new directory for=20
> 'internal' headers. =20
> > External applications can then be built without the internal header=20
> > directory being on their include path.  This would then=20
> make it very=20
> > easy to detect if a dependency on the internal headers has=20
> 'drifted'=20
> > into the API.
> >
> > The internal headers could be called something like=20
> odeModelInternal.h=20
> > or odeModel_Internal.h
> >
> > Note you obviously don't have to declare structures and function=20
> > prototypes in headers.  They can be declared in .c files
> >
> > yours Andrew
> >
> >> -----Original Message-----
> >> From: sbm...@li...
> >> [mailto:sbm...@li...] On=20
> Behalf Of=20
> >> Rainer Machne
> >> Sent: 12 June 2006 11:18
> >> To: SOSlib Development
> >> Subject: [SOSlib-devel] API reorganization[Scanned]
> >>
> >> Hi All
> >>
> >> the point # 1.4 API reorganization of our online development wiki
> >> (http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel)
> >>
> >> might be one thing that should be done soon, before=20
> implementing more=20
> >> functionality.
> >>
> >>
> >>
> >> For some c files we have three header files, e.g.
> >>
> >> odeModel.h
> >> odeModelStruct.h
> >> odemodeldatatype.h
> >>
> >> which confuses me a bit.
> >>
> >>
> >> In odeModel.h we have all the API function definitions, in=20
> >> odemodeldatatype.h there is only
> >>   typedef struct odeModel odeModel_t; and in odeModelStruct.h the=20
> >> odeModel structure is defined.
> >>
> >> It was initially thought, and I want to keep it that way, that=20
> >> applications include the odeModel.h file.
> >>
> >> Then we also have the
> >> #ifdef __cplusplus
> >> extern "C" {
> >> #endif
> >>   definitions in all header files.
> >>
> >> So what are the requirements for all this?
> >>
> >> The main point is to
> >>
> >> * hide structures and internal functions from calling applications.
> >>
> >> The second point is that we need to
> >>
> >> * map the C code to C++.
> >>
> >> Right?
> >>
> >>
> >>
> >> The following would be my plan:
> >>
> >> in odeModel.h
> >> * SBML_ODESOLVER_API functions
> >> * structure type definitions (only e.g. typedef struct odeModel
> >> odeModel_t)
> >>
> >> in odeModelStruct.h
> >> * the full structure declaration
> >>
> >> Questions:
> >>
> >> What about the third file in the odeModel example. Is this=20
> required?
> >>
> >> Where should we move the declarations for internal (non-API)=20
> >> functions?
> >>
> >> * in odeModel.h but e.g. outside of the extern "C" { definitions?
> >>
> >> * in odeModelStruct.h? Should we rename it then?
> >>
> >> happy about any suggestions,
> >> Rainer
> >>
> >>
> >>
> >> _______________________________________________
> >> sbmlsolver-devel mailing list
> >> sbm...@li...
> >> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>
> >
> >
> > _______________________________________________
> > sbmlsolver-devel mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >
>=20