1. 21 Apr, 2016 2 commits
  2. 10 Apr, 2016 1 commit
  3. 30 Mar, 2016 1 commit
  4. 06 Mar, 2016 1 commit
  5. 19 Feb, 2016 1 commit
  6. 18 Feb, 2016 1 commit
  7. 17 Feb, 2016 1 commit
  8. 12 Feb, 2016 1 commit
    • Pieter Hintjens's avatar
      Problem: gyp does not build tests · 8230c0d3
      Pieter Hintjens authored
      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 :)
      8230c0d3
  9. 11 Feb, 2016 5 commits
    • Luca Boccassi's avatar
      Problem: typo in CMakeLists "matches" keyword · f1c4416e
      Luca Boccassi authored
      Solution: must be upper case
      f1c4416e
    • Luca Boccassi's avatar
      Problem: typo in CMakeLists.txt, can't use sodium · 1e691503
      Luca Boccassi authored
      Solution: check for WITH_LIBSODIUM configure option instead of
      WITH_SODIUM
      1e691503
    • Pieter Hintjens's avatar
      Problem: tweetnacl sources are a mess · f8ed793f
      Pieter Hintjens authored
      - 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
      f8ed793f
    • Pieter Hintjens's avatar
      Problem: cmake fails with #error None of the ZMQ_USE_* macros defined · ddbbe3b4
      Pieter Hintjens authored
      This happens if you first configure with autotools, and then run
      cmake. The problem is that the compiler finds the old src/platform.hpp
      before looking for the one generated by CMake. Further, there are a
      set of macros that configure passes via the command line, yet CMake
      passes via platform.hpp. (HAVE_xxx for pollers, at least.) This means
      you can't do a CMake build using the autotools platform.hpp.
      
      Solution: remove any src/platform.hpp when running cmake. This is a
      workaround. I'll fix the inconsistent macros separately.
      ddbbe3b4
    • Pieter Hintjens's avatar
      Problem: use of libsodium vs. tweetnacl is confused · b49a6041
      Pieter Hintjens authored
      It's unclear which we need and in the source code, conditional code
      treats tweetnacl as a subclass of libsodium, which is inaccurate.
      
      Solution: redesign the configure/cmake API for this:
      
      * tweetnacl is present by default and cannot be enabled
      * libsodium can be enabled using --with-libsodium, which replaces
        the built-in tweetnacl
      * CURVE encryption can be disabled entirely using --enable-curve=no
      
      The macros we define in platform.hpp are:
      
          ZMQ_HAVE_CURVE    1        //  When CURVE is enabled
          HAVE_LIBSODIUM    1        //  When we are using libsodium
          HAVE_TWEETNACL    1        //  When we're using tweetnacl (default)
      
      As of this patch, the default build of libzmq always has CURVE
      security, and always uses tweetnacl.
      b49a6041
  10. 08 Feb, 2016 1 commit
    • Luca Boccassi's avatar
      Problem: CMake uses command added in 2.8.12 · 918c1ec6
      Luca Boccassi authored
      Solution: bump CMake required version to 2.8.12 to avoid:
      
      CMake Error at tests/CMakeLists.txt:110 (target_include_directories):
        Unknown CMake command "target_include_directories".
      918c1ec6
  11. 01 Feb, 2016 1 commit
  12. 29 Jan, 2016 1 commit
  13. 27 Jan, 2016 1 commit
  14. 14 Jan, 2016 1 commit
  15. 18 Dec, 2015 3 commits
  16. 08 Dec, 2015 1 commit
    • Ilya Kulakov's avatar
      Add the VMCI transport. · 68b13fbd
      Ilya Kulakov authored
      VMCI transport allows fast communication between the Host
      and a virtual machine, between virtual machines on the same host,
      and within a virtual machine (like IPC).
      
      It requires VMware to be installed on the host and Guest Additions
      to be installed on a guest.
      68b13fbd
  17. 24 Oct, 2015 1 commit
  18. 23 Oct, 2015 3 commits
  19. 18 Oct, 2015 1 commit
  20. 19 Sep, 2015 1 commit
  21. 14 Sep, 2015 1 commit
  22. 11 Sep, 2015 1 commit
    • Pieter Hintjens's avatar
      Problem: cannot build single test case in tests · d416ffce
      Pieter Hintjens authored
      This is due to the mangled include of platform.h, which was to make
      CMake happy.
      
      Solution: in CMakeLists.txt, define USING_CMAKE and then look for
      platform.h in current directory if that is defined, else look in
      ../src/ as one would expect.
      d416ffce
  23. 21 Aug, 2015 1 commit
  24. 14 Aug, 2015 1 commit
  25. 05 Jul, 2015 1 commit
    • Jens Auer's avatar
      "zero-copy" raw_decoder · 36797936
      Jens Auer authored
      A memcpy is eliminated when receiving data on a ZMQ_STREAM socket. Instead
      of receiving into a static buffer and then copying the data into the
      buffer malloced in msg_t::init_size, the raw_decoder allocates the memory
      for together with the reference-counter and creates a msg_t object
      on top of that memory. This saves the memcpy operation.
      
      For small messages, data is still copied and the receive buffer is reused.
      36797936
  26. 06 May, 2015 1 commit
  27. 05 May, 2015 1 commit
  28. 11 Mar, 2015 4 commits