The last release (0.2.0) had the libtool version (current:revision:age)
set to 1:0:0. Since this release doesn't add/change/remove any
interfaces, only 'revision' is increased, resulting in 1:1:0.
http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
Frontends using libsigrok don't need to be recompiled or relinked.
These two drivers are currently unfinished and don't work, so disable
and "unhook" them for now in preparation of the next libsigrok release.
They're still in the git repository, but not hooked up to the build
system, so that they won't get detected or built, and also don't end up
in the release tarball.
Since link-mso19 is the only driver that currently requires libudev,
drop any reference to that, too.
It should be relatively easy to apply this patch in reverse after the
release to bring back both drivers.
These two drivers are currently unfinished and don't work, so disable
and "unhook" them for now in preparation of the next libsigrok release.
They're still in the git repository, but not hooked up to the build
system, so that they won't get detected or built, and also don't end up
in the release tarball.
Since link-mso19 is the only driver that currently requires libudev,
drop any reference to that, too.
It should be relatively easy to apply this patch in reverse after the
release to bring back both drivers.
When checking architecture-specific things, always check $host, i.e. the
architecture we're building _for_, not the one we happen to build _on_.
E.g. when cross-compiling _for_ Android (or Windows or others) it's important
to check for Android in $host; whether we happen to cross-compile _on_ a Linux
or Windows or OpenBSD or FreeBSD machine ($build) doesn't matter, only the
fact that we compile _for_ Android is important for most checks.
In the configure summary at the end also print the architecture we're
building on ($build) and the target host we build for ($host). The two are
not necessarily the same, e.g. in the case of cross-compiles.
In the summary output at the end of a configure run, explicitly mention
which versions of which libraries are required, and also the version which
pkg-config has found.
Use the canonical driver name (all-lowercase, e.g. "serial-dmm") in the
list of enabled/disabled drivers that configure prints after a run.
It's common to many drivers that they support multiple devices, so
printing one device name (e.g. "ChronoVu LA8") is seldom really correct.
E.g. the agilent-dmm, asix-sigma, brymen-dmm, colead-slm, fluke-dmm,
fx2lafw, hantek-dso, lascar-el-usb, mic-985xx, openbench-logic-sniffer,
rigol-ds1xx2, uni-t-dmm, victor-dmm, and zeroplus-logic-cube drivers
all support more than just one device.
So, just print the driver name instead which is more correct anyway
since it's specifically a list of enabled/disabled drivers.
Don't rely on the "heuristic" that 'libusb_CFLAGS' will be non-empty if
libusb-1.0 was found, but rather use the proper method of checking the
variable 'have_libusb1_0' which pkg-config will set to "yes"/"no"
depending on whether it finds the library.
- If libusb-1.0 is not found, do not compile in ezusb.c and usb.c since
they require libusb.h. The respective hardware drivers that use
libusb-1.0, and usb.c and/or ezusb.c will be excluded from the build
elsewhere in configure.ac. Rename NEED_EZUSB to NEED_USB.
- Drop the NEED_SERIAL check and always compile in serial.c. This is a
very small chunk of code, it does not depend on any external
libraries that might be missing, and it compiles on all architectures.
Thus there's no need to conditionally include or exclude it.
In order for lib autodetection and disabling of drivers (which require
libs that cannot be found) to work, the order of AC_ARG_ENABLEs,
AM_CONDITIONALs, and AC_DEFINEs needs to be changed.
All drivers start out enabled or disabled (depending on whether
the --disable-drivers option was supplied or not). Then, any driver can
be enabled or disabled explicitly via --enable-<drivername> or the
resp. --disable-<drivername> option. Finally, pkg-config checks for all
libraries are performed, and all drivers which require a library that
cannot be found are disabled explicitly (regardless of any
--enable-<drivername> option that might have been supplied).
Until now, we checked for certain (optional) libraries via pkg-config and
the configure script would abort if any of them was not found, even
though they were optional. It was up to the user to then figure out which
combination of --disable-<drivername> switches were required for his
specific OS (and set of installed libs) to get a working configure run.
Only if the user already specified enough --disable-<drivername>
switches beforehand, so that all drivers which require a missing library
were disabled, would the configure run not check for that specific lib
(and would thus not fail).
With this change, we now always unconditionally check for all libs
(required and optional) via pkg-config. However, whether an (optional) lib
is found or not, configure will not abort. Instead, it'll just disable
all drivers which need a lib that cannot be found.
The user will no longer have to supply --disable-<drivername> parameters
in order to get a working build.
The automake 'std-options' option checks whether all installed tools
and scripts have a --help and --version CLI option. This check is not
needed for libsigrok though, since it doesn't install any tools.
This adds a suite of unit tests for libsigrok. It uses the 'Check'
tool/library (apt-get install check) to run the tests.
The configure tool tries to find libcheck. If it succeeds, a
"make check" will run all tests. Otherwise, none of the tests will
be built and "make check" will not run any tests.
This also means that users who don't have 'check' installed will still
be able to build and install libsigrok just fine.
We don't need a C++ compiler for libsigrok, so don't check for one.
This would cause a build failure on all systems where there is a C compiler
but no C++ compiler installed.
We no longer use gthread (its only user was the 'demo' driver), so drop
the 'configure' check for it.
The libsigrok.pc pkg-config file is still correct, since the 'configure'
result propagates there automatically.
Don't override/overwrite CFLAGS in configure.ac, but rather amend it
with (currently) "-Wall -Wextra -fvisibility=hidden".
This properly allows users/packagers to do things like:
./configure (this will default to using "-g -O2" additionally)
CFLAGS="-g -O2" ./configure (same as above)
CFLAGS="" ./configure (no additional flags)
CFLAGS="-g -O0" ./configure (disable optimization, e.g. for valgrind use)
etc. etc.
PKG_CHECK_MODULES() checks for libusb-1.0 via pkg-config already, no
need to use a "manual" additional check via AC_CHECK_LIB() just to set
HAVE_LIBUSB_1_0 in config.h.
This helps with cross-compiling setups, among other things.
The alsa driver was out of date wrt APIs and libsigrok conventions in
general, and wasn't compiling.
This fixes the compile and updates it to _basically_ work with the current
state of analog support in libsigrok.
This is not finished/full support for ALSA analog sampling yet, though,
various TODOs remain that will be addressed later.
All frontends will have to include <libsigrok/libsigrok.h> from now on.
This header includes proto.h and version.h, both installed from the
distribution into $INCLUDE/libsigrok/ as well.
The only dynamically changed header is now version.h, which has both
libsigrok and libtool compile-time versions in it.
We no longer expect firmware files to be in the
$prefix/share/libsigrok/firmware directory, as that would require an
additional (distro) package 'sigrok-firmware' or the like to install
files into another package's (libsigrok) path, which can be problematic.
The current 'sigrok-firmware' repo's "make install" will already install
all files into $prefix/share/sigrok-firmware.
Add ACLOCAL_DIR setting and AM_PROG_AR macro for compiling with Homebrew
under Mac OS X.
Applies essentially the same change to
{libsigrok,libsigrokdecode,sigrok-cli}/{autogen.sh,configure.ac}
It may be that the same fix is needed for the other autogen.sh and/or
configure.ac files, but that hasn't been tested and therefore not in
this commit.
The next (and first) libsigrok release will be called 0.1.0.
The next (and first) libsigrokdecode release will be called 0.1.0.
The next sigrok-cli release will be called 0.3.0 (as we already had a 0.1
and 0.2 release of sigrok-cli; those did not yet use the libs, though).
sigrok-gtk and sigrok-qt didn't have any releases yet, so their version
numbers are set to 0.1.0.
Also, consistently use three numbers/digits for our version numbers.
Bert Vermeulen
Uwe Hermann
Marc Schink
Alexandru Gagniuc
Martin Ling
Peter Stuge
Pekka Nikander
Håvard Espeland
Joel Holdsworth