fswatch @1.4.0 update

[emcrisostomo (Enrico Maria Crisostomo)]

fswatch @1.4.0 update:

I stripped the darwin version check because conditional compilation based on a new Autoconf check should make this port build on SL too (I could not test it, however).

[neverpanic (Clemens Lang)]

You don't need to Cc yourself when reporting tickets. Since you're the maintainer, please add the maintainer keyword when filing bugs. When attaching patches, also add haspatch.

Committed in r124215. Snow Leopard build is at ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/28740.

[neverpanic (Clemens Lang)]

Doesn't look like it's working:

libtool: compile:  /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I. -I/opt/local/include -pipe -Os -arch x86_64 -stdlib=libstdc++ -std=c++11 -Wall -MT c++/poll_monitor.lo -MD -MP -MF c++/.deps/poll_monitor.Tpo -c c++/poll_monitor.cpp  -fno-common -DPIC -o c++/.libs/poll_monitor.o
In file included from In file included from c++/kqueue_monitor.cpp:23:
In file included from c++/kqueue_monitor.hc++/poll_monitor.cpp:21:
In file included from c++/poll_monitor.h:20:
:20:
c++/monitor.h:23:c++/monitor.h:23:12: fatal error12::  'mutex' file not found
fatal error: 'mutex' file not found
#  include <mutex>
           ^
#  include <mutex>
           ^
In file included from c++/monitor.cpp:20:
c++/monitor.h:23:12: fatal error: 'mutex' file not found
#  include <mutex>
           ^
libtool: compile:  /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I. -I/opt/local/include -pipe -Os -arch x86_64 -stdlib=libstdc++ -std=c++11 -Wall -MT c++/libfswatch_exception.lo -MD -MP -MF c++/.deps/libfswatch_exception.Tpo -c c++/libfswatch_exception.cpp -o c++/libfswatch_exception.o >/dev/null 2>&1
libtool: compile:  /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I. -I/opt/local/include -pipe -Os -arch x86_64 -stdlib=libstdc++ -std=c++11 -Wall -MT c++/event.lo -MD -MP -MF c++/.deps/event.Tpo -c c++/event.cpp -o c++/event.o >/dev/null 2>&1
depbase=`echo c/libfswatch.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
	/bin/sh ./libtool  --tag=CXX   --mode=compile /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I.   -I/opt/local/include  -pipe -Os -arch x86_64 -stdlib=libstdc++ -std=c++11 -Wall -MT c/libfswatch.lo -MD -MP -MF $depbase.Tpo -c -o c/libfswatch.lo c/libfswatch.cpp &&\
	mv -f $depbase.Tpo $depbase.Plo
depbase=`echo c/libfswatch_log.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
	/bin/sh ./libtool  --tag=CXX   --mode=compile /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I.   -I/opt/local/include  -pipe -Os -arch x86_64 -stdlib=libstdc++ -std=c++11 -Wall -MT c/libfswatch_log.lo -MD -MP -MF $depbase.Tpo -c -o c/libfswatch_log.lo c/libfswatch_log.cpp &&\
	mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I. -I/opt/local/include -pipe -Os -arch x86_64 -stdlib=libstdc++ -std=c++11 -Wall -MT c/libfswatch_log.lo -MD -MP -MF c/.deps/libfswatch_log.Tpo -c c/libfswatch_log.cpp  -fno-common -DPIC -o c/.libs/libfswatch_log.o
libtool: compile:  /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I. -I/opt/local/include -pipe -Os -arch x86_64 -stdlib=libstdc++ -std=c++11 -Wall -MT c/libfswatch.lo -MD -MP -MF c/.deps/libfswatch.Tpo -c c/libfswatch.cpp  -fno-common -DPIC -o c/.libs/libfswatch.o
1 error generated.
make[3]: *** [c++/monitor.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
c/libfswatch.cpp:21:10: fatal error: 'atomic' file not found
#include <atomic>
         ^
1 error generated.
make[3]: *** [c++/poll_monitor.lo] Error 1
libtool: compile:  /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I. -I/opt/local/include -pipe -Os -arch x86_64 -stdlib=libstdc++ -std=c++11 -Wall -MT c++/path_utils.lo -MD -MP -MF c++/.deps/path_utils.Tpo -c c++/path_utils.cpp -o c++/path_utils.o >/dev/null 2>&1
1 error generated.
make[3]: *** [c++/kqueue_monitor.lo] Error 1
libtool: compile:  /opt/local/bin/clang++-mp-3.4 -DHAVE_CONFIG_H -I. -I/opt/local/include -pipe -Os -arch x86_64 -stdlib=libstdc++ -std=c++11 -Wall -MT c/libfswatch_log.lo -MD -MP -MF c/.deps/libfswatch_log.Tpo -c c/libfswatch_log.cpp -o c/libfswatch_log.o >/dev/null 2>&1
1 error generated.
make[3]: *** [c/libfswatch.lo] Error 1
make[3]: Leaving directory `/opt/local/var/macports/build/_opt_mports_dports_sysutils_fswatch/fswatch/work/fswatch-1.4.0/libfswatch'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_mports_dports_sysutils_fswatch/fswatch/work/fswatch-1.4.0/libfswatch'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_mports_dports_sysutils_fswatch/fswatch/work/fswatch-1.4.0'
make: *** [all] Error 2
make: Leaving directory `/opt/local/var/macports/build/_opt_mports_dports_sysutils_fswatch/fswatch/work/fswatch-1.4.0'
Command failed:  cd "/opt/local/var/macports/build/_opt_mports_dports_sysutils_fswatch/fswatch/work/fswatch-1.4.0" && /usr/bin/make -j8 -w all
Exit code: 2

Thanks for trying anyway, though.

[neverpanic (Clemens Lang)]

Actually, the same seems to be happening on Lion and Mountain Lion as well. You might want to look into this, since those previously built fine AFAIR.

[emcrisostomo (Enrico Maria Crisostomo)]

Hi,

Thank you very much: you remember correctly, this was compiling fine everywhere but on SL but it was v. 1.3.9. Now, in v. 1.4.0, I moved the engine to a dynamic library and I made it thread safe using C++11 constructs and classes. Since it's failing just on those headers (such as mutex and atomic) it probably means that although the compiler declares to conform to the C++11 standard (this is checked in the configure step plus the compiler blacklist you suggested), the library does not (and I do not perform Autoconf checks on each and every header).

That means that I will have to conditionally compile that stuff too if I want fswatch to work on SL, L and ML, which I certainly do.

Please, leave this on hold because fixing this one will take some hours at least: I hope to nail them all otherwise there'll be some other iteration.

Thanks, -- Enrico

[neverpanic (Clemens Lang)]

Yeah, unfortunately if you want full C++11 support you're limited to Mavericks and beyond.

The rationale behind that is that only libc++, Apple's new C++ runtime library, supports C++11 while the previous libstdc++ from GCC is stuck at the equivalent of what it was in GCC 4.2 due to licensing reasons.

However, the default C++ runtime didn't change until Mavericks, which means on 10.8 and below (where libstdc++ is being used) the compiler understands C++11 (because you can switch to libc++ manually) but the runtime does not. Switching to libc++ for this port is not an option either, because both runtimes are incompatible and cannot be mixed in the same binary, i.e., you could no longer link against your library and a different C++ library in MacPorts. Consequently, the choice of C++ runtime library cannot be made locally for a single port, but must be done at a global level in all of MacPorts at once, and we're not confident enough and lack the manpower to ignore Apple's default and go with libc++ on 10.7 and beyond.

[emcrisostomo (Enrico Maria Crisostomo)]

Replying to cal@…:

Yeah, unfortunately if you want full C++11 support you're limited to Mavericks and beyond.

The rationale behind that is that only libc++, Apple's new C++ runtime library, supports C++11 while the previous libstdc++ from GCC is stuck at the equivalent of what it was in GCC 4.2 due to licensing reasons.

However, the default C++ runtime didn't change until Mavericks, which means on 10.8 and below (where libstdc++ is being used) the compiler understands C++11 (because you can switch to libc++ manually) but the runtime does not. Switching to libc++ for this port is not an option either, because both runtimes are incompatible and cannot be mixed in the same binary, i.e., you could no longer link against your library and a different C++ library in MacPorts. Consequently, the choice of C++ runtime library cannot be made locally for a single port, but must be done at a global level in all of MacPorts at once, and we're not confident enough and lack the manpower to ignore Apple's default and go with libc++ on 10.7 and beyond.

Thank you very much for the explanation, now that's clear.

I've just submitted (yet) another patch for 1.4.1: I added an Autoconf check for <mutex> and <atomic> and disabled that functionality on systems missing the new runtime.