The header coap.h should be the only header file a user has to include
to get functions from the libcoap available. Bu we have to provide not
only the header interface to the user, the user needs also some extra
information like the libcoap version or upstream related infos.
To get these automated in to a shipped coap.h header file we simple can
use some autotool magic and expand some macros while configure is
running and pasing i/c/coap.h.in. By this we can currently add the
following macro variables:
LIBCOAP_PACKAGE_BUGREPORT -> upstream email contact
LIBCOAP_PACKAGE_NAME -> the used package name (libcoap)
LIBCOAP_PACKAGE_STRING -> package name + version
LIBCOAP_PACKAGE_URL -> upstream homepage
LIBCOAP_PACKAGE_VERSION -> the current used version
All these macros variables are expanded from the respective macro names
from the configure run. The variables are prefixed because this with
LIBCOAP_ to not get name clashing on the user side while running the
autotools of the users project.
There are probably more predefined macros needed, but they can be easily
added later into include/coap/coap.h.in.
As we never want to break the API it makes no deeper sence to use a
numbered version '1.0' as this is the same as like a simple '1'.
The defined API number is used within the library so a defined version
'1.0' is also used for the namimg inside the library and other tools
reading them from the library.
Let's reduce the API version to '1' and simplify the naming for the
library by this.
Simplifying the various definition for the currently supported
platforms. These are now Linux, Solaris and Darwin platforms. This will
hopefully grow up the next time but for now we only handle some extra
CFLAGS definitions and one extra define for Darwin. So there is not
really a need to handle this in two extra 'case switch' loops.
We have there some additional CFLAGS (right now only extra compiler
switches). There is some "special" handling needed for getting this
info into the doxygen configuration. This switches are related on the
platform the build is running.
This commit is based on a suggestion from Bill Bennet.
With this change doxygen is also creating a call and caller dependency
graphic for global functions. This is helpful for understanding the mode
of action inside the libcoap.
Suggested-by: Bill Bennet <william.bennett@netcommwireless.com>
bzip2 creates archives that are better compressed than the default gzip
format. So running 'make dist' is creating a libcoap-VER.tar.bz2, you
can create a *.tar.gz by running 'make dist-gzip' if you prefer.
The created bzip2 archive is currently 27% smaller than the respective
gzip archive.
$ ls -sh libcoap-4.1.2.tar.*
372K libcoap-4.1.2.tar.bz2
476K libcoap-4.1.2.tar.gz
After including the doc/ and the tests/ folder under the hood of the
autotools now adding the examples/ foolder too.
The user is now able to add the build of the example binarys if
configure is called with '--enable-examples' as option. The example
binarys will not be build by default!
Currently only 'coap-client', 'coap-server' and 'rd' is build.
Some compilers (clang, e.g.) just emit a warning that the tested
flags are not supported. As the macro does not recognize this,
we must pass -Werror as EXTRA_FLAG to exclude the unknown flags.
For Solaris, XPG4v2 must be enabled for ancillary data while the compiler flag
-std=c99 restricts the code to C99 and nothing else. To make this work anyway,
we have to use the following compiler flags:
-D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED=600 -D__EXTENSIONS__=1
clang has dropped support for this warning and therefore emits
warnings when it is used as a compiler flag.
configure now uses AX_CHECK_COMPILE_FLAG[0] to check for compiler support.
[0] http://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html
Because local m4 macros are located in the sub-directory m4, autogen.sh
must not remove that directory but only clean the libtool-generated files.
This option is used to extract function names from C header files
but is not supported by all versions of ctags. In particular, the
version included with GNU Emacs does not recognize it. This simple
test checks if '--c-kinds=f' is recognized and emits a warning
otherwise.
Doing up some housekeeping around the used CFLAGS.
To be more generic put the default declaration for additional warning
CFLAGS into configure.ac and clean up the Makefile.am's.
There are the default CFLAGS variable that is a global variable if not
re adjusted inside the different targets.
The second variable for CFLAGS is the AM_CFLAGS definition that is used
inside a Makefile as a global variable.
There is also the possibility to graduate the CFLAGS for a single
target. But currently there are nothing more than one target within each
Makefile so we can set for now the target specific CFLAGS to the
AM_CFLAGS.
A new variable called WARNING_CFLAGS is inside the configure.ac created,
this variable holds all the warnings flags inside. The Makefile.am's are
taking the values and is setting the variable AM_CFLAGS which is used in
the target specific CFLAGS. Also the options 'DWITH_POSIX' and
'D_GNU_SOURCE' are now appended to the CFLAGS if the configure script is
detecting a *-[uc]linux* system.
To let the previous added configure option '--enable-tests' really build
the testdriver binary adding the needed changes to the files in the main
folder.
Finally adding a new Makefile.am within the tests/ folder.
Adding a configure option to enable the build of the unit test binary.
This commit is just the configure option, the implementation into the
folder tests/ will follow!
Doxygen supports the creation of DOT graphics, but this depends on the
existence of the 'dot' binary on the build host. Adding a check for dot
and disable the support within the Doxygen file for DOT graphics if dot
can't be found.
To install the doxygen output, which is generated within doc/html/,
adding the needed checks for the doxygen binary to configure.ac and also
adding the needed doc/Makefile.am file.
Finally tuning doc/Doxyfile.in to let the autotools write the needed
informations into this file while generating the finally created
doc/Doxyfile.
Starting to add some checks while configure runs. We are starting with
support for the classical linux system, kFreeBSD would be fine to
supporting too!
To reduce the places to define the package versions setting up the
version string by m4_define macros.
The complete substitution through the config files will be done
automatically by autoconf.
To help the users of the libcoap and especially the linker on the users
machines adding a libcoap.pc file that will be installed while the call
of 'make install'.
To develop something libcoap related people need the public header files
to include the function definitions into their projects.
The public libcoap headers will be installed into the system by the
current order like
.
└── include
└── coap
├── address.h
├── async.h
├── bits.h
├── block.h
├── coap.h
├── coap_io.h
├── coap_time.h
├── debug.h
├── encode.h
├── hashkey.h
├── mem.h
├── net.h
├── option.h
├── pdu.h
├── prng.h
├── resource.h
├── str.h
├── subscribe.h
├── t_list.h
├── uri.h
├── uthash.h
└── utlist.h
That's not final! Currently the public header files include the locally
by the autoconf generated coap_config.h header file. These includes have
to be removed before we can call the header really public headers!
Start adding basic files for generating all the needed files to create a
working build environment by the autotools. By this currently only the
shared library of libcoap is build.
There is no API version implemented! This has to be done later.
Carsten Schoenert