Re: [Bacnet-developers] Source Code Layout - Building 'generic' library with everything (using bacnet-stack-0.8)

[Steve K. <st...@ka...>]

Hello Christoph,

> We are currently planing on building a BACNet client, using the open source
> BACNet stack. This client will be available on multiple platforms. E.g. Linux
> x86, x64, PPC, ARM and maybe Windows (there might be some guys using
> this OS ;-)).

That sounds like a fun project and a useful client.

> To provide a uniform compilation environment, allowing to
> cross-compile all systems at once We had to extract the corresponding files
> from the tarball into our compilation structure. While We did this We copied all
> referenced files from the following directories:
>  - ./src
>  - ./ports/linux,
>  - ./ports/windows,
>  - ./demos/object
>  - ./demos/handler
>
> into a single ./src folder. All header files were copied into a single ./include
> folder. The full layout is attached in the includeTree.txt and srcTree.txt files.
>
> We compiled the epics and bacserv tool and tested the final lib on the
> aforementioned systems, by simply browsing a running bacserv application
> via the epics tools.
>
> Now there are the following questions I would like to ask:
> 1) Could Our reorganization of the source files cause any latent issues resp.
> what was Your intention of organizing the source code as it is now?

I doubt that your reorganization will cause any latent issues.  My
intention for the organization of this library was to make the library
easy to maintain, test, and build for multiple platforms, compilers,
and targets. It's fairly easy to know which type of files are expected
go in which folders.

> 2) As We have interpreted the source code, it looks like that the actual library
> is directly focused on the stack, without any higher-level functionalities. To use
> such a user must include the source, provided by ./demos/object resp.
> ./demos/handlers. Is Our interpretation correct and if so: Why was this functionality
> put into the demos and not into another higher-level utility library?

Each product has its own set of BACnet objects required, as well as
the way the objects interact with the other pieces of firmware or
software in the product  The intent was to show that demo/ was only an
example, but it could be used as-is.  Most of the products I have
worked on have a set of demo/objects that are custom for the project,
and only start with files from demo/objects.  I copy the BACnet object
C files to my local product directory, and modify them as needed. I
try to keep the headers in demo/object intact, but sometimes I have to
add extra functions to the BACnet object files.  Most of the
demo/handlers/ examples can be used as-is, but sometimes a project or
product has a requirement that makes changing those necessary.
However, for the majority of BACnet projects and products using the
library, bacnet-stack/src/ files will not need modified since they
contain core behavior.

> 3) The folder ./ports/linux/ does not only contain library-only code but also the
> test 'rx_fsm.c'. What was your intention on directly putting the test into this
> folder and not providing another folder structure to better express the context of
> the containing files? E.g. an alternative would be:
> ./ports/linux/lib/    -    Holds all the library relevant code
> ./ports/linux/include  -  Holds all the internal header files
> ./ports/linux/pub_include   -   Holds all public 'library user'-specific header files.
> ./ports/linux/tests/...    -   All test-relevant code with source, test scripts, etc.

The /ports/linux/ is a catch-all for linux related files at the
moment.  I suppose the directory structure could be better expressed
in many ways.

> 4) Concerning Licensing: When only the folder structure has been changed, but
> not a single source file, is it then still required to publish the library?

Each source file has the text of their license within it.  Typically
only the files in bacnet-stack/src are licensed with GPL with the
exception for embedding (like eCos).  All the other files are MIT or
Expat license or public domain.  Changing the folder structure doesn't
affect the licenses.  It just makes it harder to sync with the trunk
if you ever want to do that in the future.

For most of the simple products I create that use this BACnet library,
my directory structure is:
src/main.c
src/device.c
src/ai.c
src/bacnet-stack

For more complex product families, my directory structure may look like:
src/doc/
src/drivers/mb9bf/
src/drivers/lpc24xx/
src/drivers/lpc17xx/
src/drivers/stm32f10x/
src/drivers/avr/
src/library/bacnet-stack/
src/library/efsl/
src/library/lwip/
src/library/product/
src/platform/product1/
src/platform/product2/
src/platform/product3/
src/test/
src/Makefile

Best Regards,

Steve