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

[Christoph Z. <cz...@rs...>]

Hi Steve,

Thanks for answering my questions.

Best Regards,
Christoph Zach

On Wednesday 16 October 2013 11:35:59 Steve Karg wrote:
> 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
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> BACnet-developers mailing list
> BAC...@li...
> https://lists.sourceforge.net/lists/listinfo/bacnet-developers