In file included from cmd/dirmerge.cpp:17:
In file included from ./lib/command.h:22:
In file included from ./lib/app.h:28:
In file included from ./lib/cmdline_option.h:28:
In file included from ./lib/mrtrix.h:30:
/usr/local/include/Eigen/array:8:4: error: The Eigen/Array header does no longer exist in Eigen3. All that functionality has moved to Eigen/Core. #error The Eigen/Array header does no longer exist in Eigen3. All that functionality has moved to Eigen/Core.
^
Haven’t come across that one before… As far as I can tell, what’s happening is that the compiler tried to use the Eigen/Array header instead of the desired C++ standard array header. I’m not entirely sure how that could happen, but I notice that the path to the Eigen headers is provided explicitly to the compiler. Did you set this yourself at the configure stage? Maybe you used something like this?
Actually, it looks to me like you don’t need to set the EIGEN_CFLAGS at all, given that ./configure worked when it seemed to be set incorrectly. Have you tried running just a straight ./configure…?
I am on Mac OS X 10.11.3 with Xcode 7.2 and current macports.
Eigen 3 was installed through macports (sudo port install eigen3).
Qt 5.5 was installed through its official installer.
./configure output:
MRtrix build type requested: release
Detecting OS: darwin
Checking for C++11 compliant compiler [clang++]: 4.2.1 - tested ok
Detecting pointer size: 64 bit
Detecting byte order: little-endian
Checking for variable-length array support: yes
Checking for non-POD variable-length array support: no
Checking for zlib compression library: 1.2.5
checking for Eigen 3 library: 3.2.8
Checking shared library generation: yes
Checking for Qt moc: moc (version 5.5.0)
Checking for Qt qmake: qmake (version 5.5.0)
Checking for Qt rcc: rcc (version 5.5.0)
Checking for Qt: 5.5.0
writing configuration to file './release/config': ok
From your eigen3 path, I assume you used homebrew to install eigen3?
In my experience, macports is much more mature and offers a much smoother experience… In any case, make sure you are using only one of both systems.
@jdtournier: I am not sure about the other Mac OS X developers, but I would vouch for removing the homebrew references and sticking to just macports. With the current instructions, what I have seen happening on quite a few occasions is this: 1) people try macports first, but for some unrelated reason they didn’t manage to build the software on the first go; 2) they try homebrew instead hoping that this might fix their initial problem; 3) the duplicated and incompatible dependencies will cause havoc
Actually, I think Pim’s issue might be more related to him installing from source, which is currently the “recommended” way on the Wiki. Apparently, this may require special care of the include-path.
Personally, I never experienced any issues with Eigen when installing through Homebrew. Just recently, on a clean system, I did brew install eigen, and then plain and simple ./configure and ./build. No need to set any environment variables. Worked straight out of the box.
I agree with @bjeurissen that Macports and Homebrew don’t work well together, but I would refrain from favouring one over the other on the wiki. Many users might already have one of both installed, and would want to work with that. If they don’t, I would personally recommend Homebrew (that’s just me, plenty of port vs brew debates on the web already).
Therefore, I would suggest expanding the build instructions for both Homebrew and Macports, but remove or at least discourage the option of installing from source.
@dchristiaens: I didn’t know unpacking the source was recommended. In that case I would favour a single option: unpacking the source and remove the homebrew and macports stuff. Developers will go their own way, but for users it is just too confusing at the moment and I think we should hold their hand and point them to the single solution.
I tried to clarify some of the OS X installation instructions here: https://github.com/MRtrix3/mrtrix3/pull/471. I only use homebrew, against which I have tested it. So let me know or feel free to change it if any of the other ways don’t work.
@bjeurissen: Fine with me too, as long as it’s properly documented. Maybe just add the command of your last post to the docs?
On a more general note, I am wondering if we could automate the Eigen install altogether (ideally for all systems)? I assume the licence doesn’t allow to simply ship Eigen with MRtrix. However, if configure doesn’t detect an existing installation, it could clone the latest version into, say, mrtrix3/Eigen and proceed from there. Main issue is that Eigen uses Mercurial instead of git, which is not installed by default. Thoughts?
In the code, we’d include the Eigen headers as #include <Eigen/Array>, etc. The correct path to add to the CFLAGS is therefore that enclosing the main Eigen folder, not the Eigen folder itself. There shouldn’t have been a conflict using the correct path.
As to how to fix the instructions, I think providing clear instructions for the 3 different approaches is probably the best, with a solid default recommendation. @maxpietsch tells me you can install all the dependencies including Qt5 via homebrew, so this seems like the simplest and least likely to trip up users. No idea whether Qt5 can be installed via macports, but assuming it can’t, the requirement to also install the massive Qt5 installer (and remember where it was installed) makes the overall installation process more complex, and hence more error-prone. So that would argue for macports not being the default option. But given that many people will swear by macports, we need to provide instructions for it. The direct download route should probably be the last resort…
Been following this thread pretty loosely, so apologies if I’m repeating information. Just wanted to say you can install Qt5 via MacPorts, it’s documented here.
Disclaimer: I haven’t actually used this, I did my installation with homebrew which worked a charm : )
OK, I guess that answers that question then… I think we should move the conversation over to the relevant GitHub issue - I can’t keep track of the discussion on two fronts at once…
