Commit Graph

305 Commits

Author SHA1 Message Date
Luca Boccassi
f18463f323 Problem: mkdtemp not available on all platforms
Solution: check for availability in autoconf and cmake, and if not
available fall back to random file name rather than random directory.
2016-04-11 00:18:51 +01:00
Matt Powley
f2018ab317 Fixes for Windows XP compatibility
A Visual Studio build from master (commit id: dac5b45dfb) using the v140_xp toolset yields a binary that is not XP compatible.

Two libraries contain exports that cannot be found:
 -  IPHLPAPI.DLL : if_nametoindex
 - KERNEL32.DLL : InitializeConditionVariable

The latter export is already dealt with in the file './src/condition_variable.hpp'; however this requires setting the _WIN32_WINNT pre-processor definition.
I am not experienced enough to figure a work around for the 'if_nametoindex' method, so I have created a new pre-processor definition 'ZMQ_HAVE_WINDOWS_TARGET_XP' and removed the calling of the function with the limitation that these builds cannot handle a IPv6 address with an adapter name.

To make it easier for people targeting XP with an MSVC build I have modified the MSBuild property file to add/modify the pre-processor definitions if they are building using a XP targeting tool set; such as v140_xp.
2016-03-31 15:45:00 +01:00
Matt Powley
260860dea1 Add .gitignore for Visual Studio builds in the 'builds/msvc' folder
* Added a new .gitignore file for excluding Visual Studio build output any popular plug-in generated content. (This was copied from the GitHub project https://github.com/github/gitignore).
* Removed the basic ignore settings from the root folder in favour of more precision within the subfolder's .gitignore file
* Added the new VC compiler's experimental Intellisense database file
2016-03-31 14:51:36 +01:00
Matt Powley
0e405a5a77 Use vs2015 MSBuild property sheets in older projects
All the older (vs2010 -> vs2013) projects had copies of the Visual Studio 2015 MSBuild applied to them when running the 'configure.bat' batch file. Any modifications to a property sheet was not applied to the other Visual Studio versions' projects unless the batch file was re-executed.

* Modified the older projects to reference the Visual Studio 2015 property sheets so changes are immediately applied
* Removed the batch file copy steps (which left the repository very dirty after execution)
2016-03-31 14:51:23 +01:00
Pieter Hintjens
396237f871 Problem: MSVC builds instructions aren't entirely clear
Solution: update them.
2016-03-30 14:19:20 +02:00
Luca Boccassi
dc27ad41d2 Problem: coveralls uses wrong path on Trusty
Solution: pass built-root when calling coveralls, to help it find the
right path to the source code.
2016-03-19 21:55:03 +00:00
Luca Boccassi
00e0957640 Problem: false positive on valgrind 3.10
Solution: update builds/valgrind/valgrind.supp to ignore glibc's
__libc_freeres calls. This code runs after the program exits, and
tries to de-allocate memory allocated internally by glibc, so it has
nothing to do with libzmq code. This suppression is added by default
in newer versions of Valgrind, not yet available on older
distributions.
2016-03-19 21:54:52 +00:00
Luca Boccassi
ebc7316069 Problem: CI doesn't run Valgrind
Solution: run Valgrind only on the default Linux build to avoid
increasing the runtime.
2016-03-19 21:54:52 +00:00
Benjamin Henrion
516efa46c0 add some doc for docker android compilation 2016-03-18 13:54:20 +01:00
Luca Boccassi
15fd419f22 Problem: test_large_msg requires 2GB of free RAM
Solution: remove temporarily until proper message limits have been
implemented, then a more granular test case can be added without
such high requirements which are problematic in embedded environment,
build systems, VMs and CI systems
2016-03-16 21:47:58 +00:00
Luca Boccassi
0cd7c0f807 Problem: no code coverage in CI
Solution: add new coverage build, and upload results to coveralls.io
2016-03-13 22:23:56 +00:00
Osiris
a6392b9e74 Problem: Windows PDB not created for RELEASE targets
Solution: Modified projects to create PDB file for RELEASE targets
	- also spread precompiled settings to all DevStudio solution versions

This change affects Windows builds only
2016-03-11 14:48:30 -06:00
Pieter Hintjens
0916c17b3a Merge pull request #1842 from opedroso/PRECOMPILED
Problem: Windows Build not using precompiled headers for all targets
2016-03-05 12:59:51 +02:00
Osiris
224c0670ee Problem: Windows Build not using precompiled headers for all targets
Solution: Enabled precompiled header settings in all targets
Before build time: ~6min 49 secs
Stop  Time: Fri 03/04/2016  8:29:50.13
Start Time: Fri 03/04/2016  8:23:00.28

After build time: ~4min 19 secs
Stop  Time: Fri 03/04/2016 12:12:10.24
Start Time: Fri 03/04/2016 12:07:51.78
2016-03-05 04:47:08 -06:00
Osiris
09d003aac0 Problem: Added "make clean" to Windows build scripts
Solution: Added ability to do equivalent of a "make clean" by executing:

O:\git\libzmq\builds\msvc\build>buildall.bat clean
Start Time: Fri 03/04/2016 14:33:56.50
Cleaning without libsodium
Cleaning ..\vs2013\libzmq.sln... ()
Platform=x86
Configuration=DynDebug
Configuration=DynRelease
Configuration=LtcgDebug
Configuration=LtcgRelease
Configuration=StaticDebug
Configuration=StaticRelease
Platform=x64
Configuration=DynDebug
Configuration=DynRelease
Configuration=LtcgDebug
Configuration=LtcgRelease
Configuration=StaticDebug
Configuration=StaticRelease
Cleaning complete: ..\vs2013\libzmq.sln

Stop  Time: Fri 03/04/2016 14:34:01.84
Start Time: Fri 03/04/2016 14:33:56.50

A clean takes ~5 secs to complete.
2016-03-05 04:37:01 -06:00
Daniel Lupu
3190de8045 update Makefile.mingw32 2016-02-28 06:26:35 +02:00
Luca Boccassi
f3686e34ff Problem: make dist broken due to builds/msvc
Solution: change builds/msvc/Makefile.am to reference vcxproj files
instead of props files.
2016-02-22 11:58:36 +00:00
Luca Boccassi
391397571b Problem: make dist broken due to builds/android
Solution: change builds/Makefile.am to reference builds/android
instead of builds/qt-android.
2016-02-22 11:58:00 +00:00
Luca Boccassi
8d811474d4 Problem: make dist broken due to builds/cmake
Solution: remove references to builds/cmake/Makefile* since they no
longer exist.
2016-02-22 11:57:09 +00:00
Osiris
b3d5fa63a0 Problem: Several problems found by Coverity Static Analyzer
Solution: The Coverity Static Code Analyzer was used on libzmq code and found
many issues with uninitialized member variables, some redefinition of variables
hidding previous instances of same variable name and a couple of functions
where return values were not checked, even though all other occurrences were
checked (e.g. init_size() return).
2016-02-21 15:49:47 -06:00
Osiris
79538ed651 Problem: Windows build not using precompiled header
Solution: Phase II - made compile using precompiled header
2016-02-18 11:35:35 -06:00
Pieter Hintjens
27fe489843 Problem: VC++ gives warnings on inet_addr
Solution: in project.gyp, define _WINSOCK_DEPRECATED_NO_WARNINGS
2016-02-18 11:46:43 +01:00
Osiris
80024eca8c Problem: Windows build script requires edit for DevStudio version
Solution: Use CMD.EXE environment variable to extract DevStudio version
number and build using it. This even supports machines with multiple
DevStudio versions installed, as long as the build for each version is
done on a separate window with the correct environment.
If multiple version builds are desired from a single CMD.EXE, edit the
buildall.bat file to uncomment the build statements for each specific
version desired.
2016-02-17 09:42:53 -06:00
Pieter Hintjens
3443da216f Problem: node-gyp defaults to -fno-rtti, which breaks libzmq
Solution: override in project.gyp, for Linux and OS/X.
2016-02-17 12:06:45 +01:00
Pieter Hintjens
c78e4f33a3 Problem: if src/platform.hpp still exists, gyp uses this
Gyp needs its own platform.hpp; there is no way to delete this
file automatically.

Solution: copy gyp's platform.hpp into src, so that things build
properly no matter what the starting state. If you build with gyp
and then try to build using autotools' makefile, you'll get an
error from the platform.hpp.
2016-02-17 12:06:45 +01:00
Pieter Hintjens
9bebd4dce9 Problem: local build should do its own .gitignore
Solution: add .gitignore in builds/gyp
2016-02-17 12:06:45 +01:00
Pieter Hintjens
8559770cf3 Problem: in builds/gyp, socket limit is 4K on Windows
Solution: raise to 16K
2016-02-17 12:06:45 +01:00
Pieter Hintjens
bbcc79d188 Problem: tests don't build on Windows
There were numerous small issues with test cases:

- some lacked the right source file header
- some were not portable at all
- some were using internal libzmq APIs (headers)

Solution: fixed and cleaned up.
2016-02-12 15:48:37 +01:00
Pieter Hintjens
d148c3ea5d Problem: no clue how to run gyp on Windows
Solution: offer a build.bat to help the user.
2016-02-12 15:48:37 +01:00
Luca Boccassi
8bee4e2547 Merge pull request #1799 from hintjens/master
Making gyp builds work
2016-02-12 10:40:43 +00:00
Pieter Hintjens
8230c0d396 Problem: gyp does not build tests
Solution: it's a lot of work to define the tests in project.gyp
so I did this using gsl to generate the JSON, from a small XML
list of the test cases.

To keep this, and the hundreds of .mk files, away from the root
directory, I've moved the gyp files into builds/gyp, where you
would run them.

It all seems to work now. Next up, OS/X and Windows :)
2016-02-12 11:31:38 +01:00
Pieter Hintjens
a682f94a32 Problem: tcp_address.cpp won't compile on OS/X w/o ZMQ_HAVE_IFADDRS
This is rather insane since the code knows well enough what systems
support if_nametoindex. I blame this on over-use of autotools early
in libzmq's days.

Anyhow, this breaks gyp builds on OS/X.

Solution: add ZMQ_HAVE_IFADDRS to build/gyp/platform.hpp for OS/X.
2016-02-12 10:49:19 +01:00
Constantin Rack
22e830bece Merge pull request #1798 from hintjens/master
Getting gyp build working
2016-02-12 10:07:14 +01:00
Pieter Hintjens
6bef3fe9ad Problem: can't build libzmq.a using gyp
Solution: add necessary macros into builds/gyp/platform.hpp

Work for Linux now, other platforms to test.
2016-02-12 09:58:44 +01:00
Luca Boccassi
9393f06381 Problem: CI use of sodium or nacl is confusing
Solution: establish a matrix of CI options. On one axis we have the
build system (autotools, cmake, android) and on the other axis we
have the encryption options (tweetnacl, libsodium or none).
2016-02-11 22:39:36 +00:00
Luca Boccassi
01eb580739 Problem: typo in CMake platform.hpp breaks build
Solution: use ZMQ_USE_TWEETNACL as a define as expected instead of
HAVE_TWEETNACL
2016-02-11 21:41:21 +00:00
Pieter Hintjens
fde81d7e07 Problem: can't build using gyp
I'm adding gyp support so that we can easily pull in libzmq
and other C/C++ projects into gyp packages, especially via
node-gyp.

Solution: add gyp definition

This works only for Windows, OS/X, and Linux. We set a single
macro in project.gyp according to the system, and the rest is
done in builds/gyp/platform.hpp. The values in that file are
not dynamic. Your mileage will vary.
2016-02-11 22:41:01 +01:00
Luca Boccassi
0bdc5d0457 Problem: CMake CI build still clones libsodium
Solution: avoid cloning libsodium, default build is tweetnacl
2016-02-11 20:27:06 +00:00
Luca Boccassi
4f5594c2ce Problem: Android CI build uses unstable libsodium
Solution: checkout stable branch before building
2016-02-11 20:25:21 +00:00
Luca Boccassi
3420e6e0dd Problem: CI still thinks libsodium is default
Solution: build by default with tweetnacl, and add sub-build project
to test libsodium
2016-02-11 20:16:17 +00:00
Pieter Hintjens
f8ed793f76 Problem: tweetnacl sources are a mess
- they have no copyright / license statement
- they are in some randomish directory structure
- they are a mix of postable and non-portable files
- they do not conform to conditional compile environment

Overall, it makes it rather more work than needed, in build scripts.

Solution: clean up tweetnacl sauce.

- merged code into single tweetnacl.c and .h
- standard copyright header, DJB to AUTHORS
- moved into src/ along with all other source files
- all system and conditional compilation hidden in these files
- thus, they can be compiled and packaged in all cases
- ZMQ_USE_TWEETNACL is set when we're using built-in tweetnacl
- HAVE_LIBSODIUM is set when we're using external libsodium
2016-02-11 18:06:07 +01:00
Luca Boccassi
c23cc65735 Problem: no CMake Travis CI build
Solution: add builds/cmake/ci_build.sh and call it from travis.yml
2016-02-08 13:30:25 +00:00
Luca Boccassi
84544ca6e2 Problem: no CI build with tweetnacl
Solution: add builds/tweetnacl/ci_build.sh and add it in travis.yml
2016-02-08 12:31:05 +00:00
Pieter Hintjens
e0f02bdfb8 Problem: libzmq uses different build.bat style than zproject
Solution: at least for vs2015, add vs2015/build.bat to work the
same was as zproject.
2016-02-07 10:36:17 +01:00
Pieter Hintjens
0d7e7bfac0 Problem: MSVC project filters were out of date
Solution: update (with correct one from VS2015)
2016-02-06 14:12:43 +01:00
Pieter Hintjens
86aa7bb1bc Problem: commit a464eec7 really broke VS2015 builds
Took me over 8 hours to track down the cause of bizarre link
errors when building with libsodium. The VS project files are
not simple things.

Note to self and other maintainers: when someone is obviously
out of their depth, do not merge their changes to build scripts
without cynical appraisal.

Solution: undo the damage.
2016-02-05 00:25:59 +01:00
Pieter Hintjens
a3d9b46a60 Problem: Android build is slow and noisy
Solution: use --without-docs (changed from --without-documentation)
and also --quiet.
2016-02-04 11:24:25 +01:00
Pieter Hintjens
31d181effb Problem: MSVC build does not detect libsodium
Caused by error in last commit which used HAVE_LIBSODIUM instead
of HAVE_SODIUM.

Solution: use HAVE_LIBSODIUM as we do in other configure scripts.

The project is called 'libsodium' and not 'sodium'.
2016-02-03 23:45:01 +01:00
Pieter Hintjens
6a9af8ed62 Problem: can't build without libsodium from command line (MSVC)
There is an option to enable/disable libsodium via the Visual Studio
UI. This is not practical for command-line usage (via msbuild).

Solution: add configure.bat that searches for libsodium in sibling
directory to libzmq; if it finds it, defines HAVE_LIBSODIUM 1.

This is consistent with zproject, which has the same problem and
is getting the same solution for all dependency resolution on
Windows.

Note that this approach also provides a way to support tweetnacl
via a configure option.

Also, removed duplicate props files and re-copy in configure.bat
as it was an insane nightmare to update these by hand. (and not
clear that they were identical. Now it's forced.)
2016-02-03 22:44:06 +01:00
Pieter Hintjens
d218e03884 Problem: project files have tool version in two places
Leading to extra work when copying between versions of VS.

Solution: remove second unnecessary definition.
2016-02-02 22:49:15 +01:00