With gcc 5.1 released and defaulting to std=gnu11, the code will be compiled
according to different standards depending on the compiler version so we
should better specify explicitly what standard we are targetting.
C11 is now quite mature, it is supported in the just release Debian stable
(gcc 4.9) and also in old-stable (gcc 4.7), so there should be no reason to
use anything more ancient.
We also should have no reason to need any non-standard GNU extension.
So using only C11 + POSIX sounds like the best option right now.
The driver for BayLibre ACME depends on Linux-specific sysfs
interfaces to ina226 and tmp435 devices. Exclude it for different
targets.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
In order to determine the target OS when cross-compiling libsigrok
we need autotools to set the 'target_os' variable. This macro
determines the system type and sets output variables to the names
of the canonical system types.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
By avoiding g_slist_copy_deep() for now, we can easily allow libsigrok
to build against glib 2.32 (less hassle for users of stable/older
distros or OSes).
This removes an unnecessary build dependency on JDK and fixes
build troubles on systems where javac is present but JDK is not
installed and Java bindings are disabled by ./configure --disable-java.
Those need a bugfix to make them build again:
bindings/java/org/sigrok/core/classes/Context.java:92: error: method Context_create_analog_packet in class classesJNI cannot be applied to given types;
long cPtr = classesJNI.Context_create_analog_packet(swigCPtr, this, ChannelVector.getCPtr(tempchannels), SWIGTYPE_p_float.getCPtr(data_pointer), num_samples, Quantity.getCPtr(mq), mq, Unit.getCPtr(unit), unit, QuantityFlagVector.getCPtr(mqflags), mqflags);
^
required: long,Context,Vector<Channel>,long,long,long,Quantity,long,Unit,long,QuantityFlagVector
found: long,Context,long,long,long,long,Quantity,long,Unit,long,QuantityFlagVector
reason: actual argument long cannot be converted to Vector<Channel> by method invocation conversion
1 error
Makefile:3352: recipe for target 'bindings/java/sigrok-core.jar' failed
Add a driver for the DER EE DE-5000 LCR meter. This meter is based on
the Cyrustek ES51919/ES51920 chipset and communicates with the host
computer via an optional connectivity kit.
The kit uses an optoisolated unidirectional link to connect to the
meter and an USB cable on the host side. Internally the connection is
using the FTDI FT232R USB UART chip i.e. from the host computer point
of view the meter is connected into an RS-232 serial port.
This driver implements just a thin shim layer for registering the
driver and uses the es51919 module for all the actual work.
The AC_DEFINEs don't need any driver names really, those only end up
as code comments in config.h and are otherwise useless. Thus, don't
duplicate them, we already have the driver names in DRIVER().
Since AX_JNI_INCLUDE_DIR does not work for cross compilation, don't
invoke it when cross compiling. Also, add a configure option to
set the jni.h include path manually if needed.
The BeagleLogic driver needs sys/mman.h and sys/ioctl.h in order to
build, so disable the driver if those headers aren't available.
This is the case (for example) on MinGW.
The AX_CXX_COMPILE_STDCXX_11 macro is found in the autoconf-archive
package. If this is not installed, invoking the macro spits out an
error message that makes it look like a syntax error. This wraps it
in a check.
This is needed so that the C++ bindings, the header for which
references "libsigrok/libsigrok.h", can have a valid include
directory passed to build them before the headers are installed.
The FDTI library changed version, module name and also soname, so add an option to detect it
when the 0.x version is not found. The 1.x API is compatible enough for libsigrok to build.
This driver is neither working nor has it been in a compiling state for
a long time, so unhook it from the build until it is fixed and works.
The files (api.c and protocol.[ch]) are still in git, but won't end up in
released tarballs and they don't get built (neither git nor tarballs).
This also allows us to drop the otherwise unneeded dependency on libudev.
When the MSO-19 driver comes back, it should be in a form that doesn't
require the inherently Linux-only libudev anyway. See also:
http://sigrok.org/bugzilla/show_bug.cgi?id=65
This driver has been unmaintained for years, and was never good code
to begin with. It's also questionable whether it was ever useful,
particularly with the demo driver now supporting various analog
signalling.
Instead of >= 44 Makefile.am's we now only have one top-level
Makefile.am, and use the 'subdir-objects' automake option to
handle the build via non-recursive (auto)make.
This has the advantage of fewer (boilerplate or other) files and less
clutter in general, as well as performance advantages since the new
setup can build many files in parallel (with 'make -j'), not only 2 or 3
files within the same (e.g. hardware/xxxx/* subdirectory) and also since
we no longer need to build intermediate libtool helper libs per subdirectory.
A quick, non-scientific test build on a quad-core laptop with 'make -j 4'
yields a build time reduction from 35s to 19s.
All autotools features that worked before are still intact without any
regressions, including the Make targets 'install', 'uninstall', 'check',
'dist', 'clean', 'distclean' and so on, as well as all the usual portability
handling (build works on any OS, with any Make implementation such as
GNU Make or BSD Make, with any shell such as sh/ksh/zsh/bash/dash, etc. etc.)
and features such as out-of-tree build support, cross-compile support,
testsuite support (also with colored output), "silent make rules", etc. etc.
This gets us the libusb version checking mechanism itself, hopefully
making this sort of thing easier in future.
Also hotplug, device tree traversal, and lots of fixes.
Disable drivers that need serial port support if libserialport is not found.
Also, disable building various other serial port related code in that case.
The libtool current:revision:age numbers change from 1:1:0 to 1:2:0
(i.e., revision is increased) since the library source code has changed,
but no interfaces were added or changed or removed.
Details:
http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
This changes the library filename (e.g. on Linux) from libsigrok.so.1.0.1
to libsigrok.so.1.0.2, but the SONAME (+symlink) remains the same
(libsigrok.so.1) since this release is API- and ABI-compatible with the last.
We now use zip_int64_t and zip_get_num_entries() for example, which
requires at least libzip 0.10. This version was released in 03/2012,
which is old enough that we don't necessarily have to do a work-around
for older versions. Thus, simply bump the requirement to >= 0.10.
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.