[go: up one dir, main page]
Menu ▾ ▴

#70 some include files are missing from owfs-3.1p2.tar.gz release tarball

up_to_v0.8
open
nobody
None
1
2016-08-09
2016-08-08
ilovezfs
No

The build fails with the 3.1p2 release tarball with the following error:

/usr/bin/clang -DHAVE_CONFIG_H -I. -I../../../../src/include  -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -F/usr/local/Frameworks -I../include -I../../../owlib/src/include -fexceptions -Wall -W -Wundef -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wredundant-decls -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -D_THREAD_SAFE   -D_FILE_OFFSET_BITS=64 -D_BSD_SOURCE=1 -D_ISOC99_SOURCE=1 -D_POSIX_C_SOURCE=200112L -Os -w -pipe -march=native -mmacosx-version-min=10.11 -DNO_NESTED_FUNCTIONS -D_BSD_SOURCE=1 -D_ISOC99_SOURCE=1 -D_POSIX_C_SOURCE=200112L -c owusbprobe.c
owusbprobe.c:22:10: fatal error: '../../../owlib/src/include/libusb.h' file not found
#include "../../../owlib/src/include/libusb.h"

The reason is that, at minimum, the following header files are missing:

module/owlib/src/include/libusb.h
module/owlib/src/include/ow_ftdi.h

If I copy only libusb.h from the git repository, the build fails with

libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I. -I../../../../src/include -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -F/usr/local/Frameworks -I../include -fexceptions -Wall -W -Wundef -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wredundant-decls -D__EXTENSIONS__ -D_FILE_OFFSET_BITS=64 -D_BSD_SOURCE=1 -D_ISOC99_SOURCE=1 -D_POSIX_C_SOURCE=200112L -D_THREAD_SAFE -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -Os -w -pipe -march=native -mmacosx-version-min=10.11 -DNO_NESTED_FUNCTIONS -D_BSD_SOURCE=1 -D_ISOC99_SOURCE=1 -D_POSIX_C_SOURCE=200112L -c ow_com.c  -fno-common -DPIC -o .libs/ow_com.o
ow_com.c:15:10: fatal error: 'ow_ftdi.h' file not found
#include "ow_ftdi.h"
         ^
1 error generated.

Tht issue affects other files besides ow_com.c (i.e., all of them include ow_ftdi.h). This also revealed a related issue, which is that ow_ftdi.h is included even if ftdi is disabled in configure, but that's not a huge deal if the file were actually in the tarball.

If I copy both libusb.h and ow_ftdi.h from the git repository, then the build succeeds.

Some of the other header files from module/owlib/src/include may also be missing, but I have some options disabled so I'm not able to say for sure which ones, if any.

The build succeeds if I use the git repository and bootstrap with Autotools, etc.

Also, the issue in https://sourceforge.net/p/owfs/mailman/message/30219156/ is still not fixed on macOS.

Discussion

  • Jan Kandziora

    Jan Kandziora - 2016-08-08

    Should be fixed in v3.1p3. Thanks for reporting and sorry for the inconvenience.

    About the MacOS bug, currently looking for someone from the team who has access to a machine so he can fix this.

     

  • ilovezfs

    ilovezfs - 2016-08-08

    @tkkasse no problem at all. Thanks for being so responsive. Regarding the macOS bug, the original homebrew pull request where it first came up is here:
    https://github.com/Homebrew/legacy-homebrew/pull/16595

    So just a heads up that it's necessary for swig, python, etc. etc. to be enabled to trigger it, in case there's any trouble reproducing it at first.

     

  • Jan Kandziora

    Jan Kandziora - 2016-08-08

    Some say all these bugs are introduced deliberately to get in touch with users. (^.–)

    The swig/python interface is very outdated, most people are using ownet based bindings today, or implementing the owserver protocol themselves. But we should fix it anyway. Or get rid of swig/python in favor of a more popular python binding.

     

    • Matthias Urlichs

      Matthias Urlichs - 2016-08-08

      On 08.08.2016 15:53, Jan Kandziora wrote:

      The swig/python interface is very outdated, most people are using ownet based bindings today, or implementing the owserver protocol themselves. But we should fix it anyway. Or get rid of swig/python in favor of a more popular python binding.
      Let's face it, there is no sense in any of these bindings, except on
      very resource-constrained devices where every millisecond and/or
      kilobyte counts.

      Do any of these even exist? Do we need to spend time and effort
      maintaining these things (not to mention bugs when an interpreter gets
      confused by our threads)?

      I move to remove these things.
      Use owserver. Let everything else access the bus through owserver. Finished.

      I'd even support removing direct access of the bus with owhttp or
      owshell or whatever.

      --
      -- Matthias Urlichs

       
      alternate

      • Matthias Urlichs

        Matthias Urlichs - 2016-08-08

        On 08.08.2016 19:41, Matthias Urlichs wrote:

        Do any of these even exist
        Sorry: s/exist/get used/.

        --
        -- Matthias Urlichs

         
        alternate

      • Jan Kandziora

        Jan Kandziora - 2016-08-08

        Am 08.08.2016 um 19:41 schrieb Matthias Urlichs:

        On 08.08.2016 15:53, Jan Kandziora wrote:

        The swig/python interface is very outdated, most people are using
        ownet based bindings today, or implementing the owserver protocol
        themselves. But we should fix it anyway. Or get rid of swig/python
        in favor of a more popular python binding.
        Let's face it, there is no sense in any of these bindings, except on
        very resource-constrained devices where every millisecond and/or
        kilobyte counts.

        The bottleneck is the Onewire itself. We don't have to consider speed
        "problems" in any other level on the same machine.

        Kind regard

        Jan
         

  • ilovezfs

    ilovezfs - 2016-08-08

    Some say all these bugs are introduced deliberately to get in touch with users. (^.–)

    Hehe. I'm actually one of the homebrew maintainers and a script I run to detect updates found your new 3.1p2 release :)

    Our current install method for Homebrew is the following:

      def install
    system "./configure", "--disable-debug",
                          "--disable-dependency-tracking",
                          "--disable-swig",
                          "--disable-owfs",
                          "--disable-owtcl",
                          "--disable-zero",
                          "--disable-owpython",
                          "--disable-owperl",
                          "--disable-ftdi",
                          "--prefix=#{prefix}"
    system "make", "install"
  end

    Are there options there you'd "ideally" like to see added or removed? It would be really helpful to know what the "desired" upstream configuration is.

    In any case, I was able to forgo the patching in https://github.com/Homebrew/homebrew-core/pull/3688 and I shipped https://github.com/Homebrew/homebrew-core/pull/3707 instead. But I'd be more than happy to alter the configuration and push out new bottles if you have any thoughts on how you'd like to see configure tweaked.

     

    • Jan Kandziora

      Jan Kandziora - 2016-08-08

      Don't do --disable-debug. There is the runtime switch --debug which enables debug. Only if the small time for testing that switch bothers you (unlikely), you can --disable-debug. Don't do that! Reason is we have no chance to debug any user problems if you --disable-debug.

      The recommended configuration is using owserver as the owlib linking driver component, and all other tools accessing owserver instead of having owlib linked to them. The owshell tools should be there as a minium client suite. Who ever needs the language bindings can compile himself.

       

  • ilovezfs

    ilovezfs - 2016-08-08

    And how about the libusb/ftdi stuff? Should that be enabled?

    I've opened https://github.com/Homebrew/homebrew-core/pull/3710 to remove --disable-debug. Feel free to comment on that PR (or here) if there are additional tweaks you'd like.

     

    • Jan Kandziora

      Jan Kandziora - 2016-08-08

      Does this even work on MacOS?

       

      • Johan Ström

        Johan Ström - 2016-08-08

        ftdi support has been tested on MacOS, and works, yes.

         

  • ilovezfs

    ilovezfs - 2016-08-09

    I've updated the formula to be

      depends_on "pkg-config" => :build
  depends_on "libftdi"
  depends_on "libusb"

  def install
    system "./configure", "--disable-dependency-tracking",
                          "--disable-swig",
                          "--disable-owtcl",
                          "--disable-zero",
                          "--disable-owpython",
                          "--disable-owperl",
                          "--disable-swig",
                          "--enable-ftdi",
                          "--enable-usb",
                          "--prefix=#{prefix}"
    system "make", "install"
  end

    so that turns on debug, usb, and ftdi. Let me know if you'd like any other tweaks!