svn

cd ~
mkdir vscp
svn co https://m2m.svn.sourceforge.net/svnroot/m2m/trunk trunk

Other svn commands:

• Status own changes: svn status -q
• Status changes against head: svn status -qu
• Update local with changes by others: svn update
• Commit local changes to svn: svn commit
• Revert a locally modified file: svn revert PATH

Compiling for Debian

Testing was performed an a minimally configured Lenny system without any sort of graphical interface. Also my aptitude is configured so that it does NOT install recommended packages. This is not the default for Lenny. I don't think that installing recommended packages will hurt anything, but I thought it was worth mentioning.
This information assumes you are actively developing for vscp. The commands and packages needed might be a little less complicated if all you need to do is compile and install for use on a production system.

For command line utilities install packages:

• libwxbase2.8-dev
• libwxbase2.8-dbg

To build the graphical examples and vscpworks application also install:

• libwxgtk2.8-dev
• libwxgtk2.8-dbg

The last two will automatically pull in the first two while installing dependencies.

• Rebuild the configure script
  • Re-build aclocal.m4 in top level build directory (above src)
  • Rebuild configure script (note don't use autoreconf because it will not pull in the aclocal.m4 file for some strange reason)

aclocal -I m4
autoconf

• Configure, make, and install

./configure --enable-debug --enable-unicode
make
make install

VSCP Software Concerns

• Really need to rework the Makefile.in files. The substitution variables are not used according to best current practices for autotools. Certainly not even close to the way automake would build those files.
• Really should convert to automake because some of the autotools scripts and nearly every tutorial assume automake is being used. The vscp dev team probably does not have enough expertise to use autoconf without automake.
• src/vscp/common/SelectDevice.cpp (280): This looks like it is storing pointers to a stack variable (buf) in the devItem structure. That wasn't ok back in the C days for sure; maybe C++ supports this? I doubt it but I'm not a C++ expert. I think this needs to allocate some memory or better an Object. Should just convert the whole strtok() parsing to use wxStringTokenizer.