Next Previous Contents

9. Creating user defined libraries for the iPAQ

You might want to use some parts of your code in more than one program. Also some of the QT Features, which you might want to use are excluded from the QTE library for some reason (e.g. filedialog).

In this case you can create user defined libraries.

This chapter describes the creation of libuvqtutil my utility library which contains methods for config- and data-fileIO and some multiple used methods for QList handling. Additionally a QT-extension to show bargraphs and a QT-extension to draw XY-diagrams is included at the moment.

The actual versions api doc is found at http://www.uv-ac.de/libuvqtutil

9.1 General

In general a library compilation is not different from the compilation of a user program. Additionally to the coding, the source files should include some debugging functionality as well as the api description (method documentation). Especially if you develop code which might be usefull for other users, the last item is important.

As I could not yet find out, how kdevelop handles the library creation (and I did not yet find a doc for that), Im still using the manual makefile method. The makefile also it not very efficient, because I am not the great makefile expert.

9.2 The source tree of libuvqtutil.

All sources and header files are copied into a dir called libuvqtutil. At the moment, the following files are used.

The next paragraph shows the makefile variables for library creation. Mainly the Linker gets different options than program development.

         CFLAGS = -pipe -fno-exceptions -fno-rtti -c -Wall -W -fPIC -O2 $(IPAQOPT)
         LDFLAGS = -shared -Wl,-soname,ibuvqtutil.so.0.1.0 -o
        

9.3 Preparing and creating the documentation

Im using the kdoc tool to create api documentation. The header files have to be documented using a special syntax described in the kdoc documentation which should be found on your host once you have installed kdoc.

As my lib is builded from different source files, I decided to use a directory structure below the api-doc dir. Every single sourcefile is documented in its own directory. On top of that sits the index.html file, which give general lib information and provides links to the api-doc files in the subdirs.

9.4 Adding debug prints

As libraries are hard to debug (I did not find a way to do this with kdevelop) and maybe used from more than one program, the sources should provide some debug functionality using prints to stderr or syslog service.

The best way to do this under linux is a macro definition. The following lines show the macro definition section placed in the header file libuvqtglobal.h. This headerfile is included into every single source file to provide the debugging functionality.

//#define DEBUGXY
#ifdef DEBUGXY
#define MSG(string, args...) syslog( LOG_DEBUG, \
            __FILE__ ":" string, ##args )
#define MSGP(string, args...) fprintf( stdout, \
            __FILE__ ":" string, ##args )
#else
#define MSG(string, args...)
#define MSGP(string, args...)
#endif
        

As you can see I define two macros MSG and MSGP, which are empty if DEBUGXY is not set and call either syslog or fprintf otherwise.

MSG uses the linux syslog utility to debug. For this the syslog daemon has to be started on the system. The familiar standard task does not contain syslog but you can install it using ipkg install syslog. This installs and configures syslog. Syslog writes messages into the files /var/log/syslog and /var/log/messages. On the handheld syslog should only be started on manual request. To guarantee this, you have to rename /etc/rc2.d/S30syslog to /etc/rc2.d/s30syslog. If this is done, the startup does not start syslog. Manual start is done via /etc/init.d/syslog start. The option stop stops the syslogger.

MSGP justs prints the message to stdout, which is helpfull, if the program is started from the console, but goes to /dev/null in case of launched from e.g. opie/qpe.

Inside the source file, you may insert the macros for information output. The following paragraph shows an example.

  MSG( "calcMatrix[%d] : idx=%d, idy=%d, x0=%d, y0=%d, xx0=%.2f, yy0=%.2f\n",
                     __LINE__, idx, idy, x0, y0, xx0, yy0 );
  MSGP( "calcMatrix[%d] : idx=%d, idy=%d, x0=%d, y0=%d, xx0=%.2f, yy0=%.2f\n",
                     __LINE__, idx, idy, x0, y0, xx0, yy0 );
        

The __LINE__-macro inserts the line number into the debug message. Inside the macro __FILE__ is already printing the filename.

9.5 Installation of your lib

The lib itself and the headerfiles have to be copied into local directories to be found by other applications. I use /usr/local/lib and /usr/local/include for that.

A simple call make install does it. Included is the creation of a link ln -s libuvqtutil.so.0.1.0 libuvqtutil.so in the same directory.

9.6 Arm lib creation

To create an arm version, you just have to switch to qtarm and call make -f makefile.arm clean; make -f makefile.arm; make -f makefile.arm install.

The install call copies the lib and include files into /usr/local/arm-linux/xtralib and /usr/local/arm-linux/xtrainclude.

9.7 Including the lib into your programs

To use your new libs, you just have to add your inlcude path during compilation with -I/whereYourIncludeIs and your linker call with -L/whereYourLibIs. Add a -luvqtutil whare uvqtutil is my example lib. Note that the heading lib and the trailing .so is missing. The linker will extend that by its own.


Next Previous Contents