Hi Manuel,

On Thu, Nov 12, 2015 at 3:45 AM, Muñoz Manuel <manuel.munoz@ujf-grenoble.fr> wrote:

Dear all,

Thank you for your feedbacks.

After several attempts, I was finally successful with the installation of Demeter. I attach a log file summarizing the different steps I experienced (and a screenshot of the main window). I guess step 2 and 5 would have been enough:
xcode-select --install
sudo port install demeter

Indeed, several hours were required for the whole installation procedure (more than 9 hours, but my internet connection is quite slow at home...).

I can now execute athena from the terminal, and apparently it works fine. However, I observe a strange behavior : After athena is running, I must click once on the terminal window before the main menus are active in Demeter (File, Group, Energy, etc.). But when we know that, it’s ok.

And the most important, I don’t have any graphical window to display the spectra. Would you have any suggestion? (Xquartz and Aquaterm are already installed on my computer).

Thank you again for your help!
Manuel

That's great that it worked for you.

I tried again with a completely fresh install of MacPorts, starting a few days ago, and again, it did not work for me. To be clear, I have Xcode and command-line tools (as from xcode-select --install ) installed, and can compile and build many programs.

Starting with installing the latest MacPorts package, the initial

~> sudo port -v selfupdate

works fine. Similar to what you saw,

~> sudo port install xorg-server

also works, but takes at least 8 hours. Really. For me

~> sudo port install demeter

took about two days of running close to full time, And it failed. As I mentioned earlier, the demeter package depends on llvm, libgcc, gcc4.9 and gcc5.2 all of which must be built FROM SOURCE, which is completely, utterly stupid. Really, this alone pretty much convinces me that MacPorts is not a good solution for distributing Athena for Mac OS X. More later. Anyway building all these compilers and effectively building an isolated BSD user-space from source did work, and most of the dependencies and perl modules correctly installed.

What failed to install was perl-5.22-pdl. This gave a compilation error using some GSL component. I uninstalled the gsl port, successfully installed the rest of the perl modules, and got the point where

~> sudo port -v install demeter

reports
---> Computing dependencies for demeter....
---> Dependencies to be installed: p5.22-pdl gsl p5.22-pdl-stats

That is, all other required components (including the wxPerl package) were installed.   GSL (2.0) does install, but p5.22-pdl fails with with

==========================
...
/usr/bin/clang -c "-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-pdl/p5.22-pdl/work/PDL-2.013/Basic/Core"   -I/opt/local/include -pipe -Os -fno-common -DPERL_DARWIN -I/opt/local/include -fno-strict-aliasing -fstack-protector-strong -I/opt/local/include -arch x86_64 -O3   -DVERSION=\"2.013\" -DXS_VERSION=\"2.013\" "-I/opt/local/lib/perl5/5.22/darwin-thread-multi-2level/CORE"   ELLINT.c
ELLINT.xs:1736:159: error: too many arguments to function call, expected 4, have 5
GSLERR(gsl_sf_ellint_D_e,((phi_datap)[0] PDL_COMMENT("ACCESS()") ,(k_datap)[0] PDL_COMMENT("ACCESS()") ,(n_datap)[0] PDL_COMMENT("ACCESS()") ,GSL_PREC_DOUBLE,&r))
       ~~~~~~~~~~~~~~~~~                                                                                                                                      ^~
./../gslerr.h:5:37: note: expanded from macro 'GSLERR'
#define GSLERR(x,y) if ((status = x y)) {snprintf(buf,200,"Error in %s: %s", #x, gsl_strerror(status));barf("%s", buf);}
                                    ^
/opt/local/include/gsl/gsl_sf_ellint.h:84:1: note: 'gsl_sf_ellint_D_e' declared here
int gsl_sf_ellint_D_e(double phi, double k, gsl_mode_t mode, gsl_sf_result * result);
^
1 error generated.
==========================

I could not find anything about this with simple searches on the MacPorts or PDL sites, but haven't looked in great detail.
I haven't looked in great detail at what might workaround or solve this issue.

As I've said before, I find the "install from source" nature of MacPorts to be very problematic, and believe we cannot use this approach. Telling users to set aside 3 days to install Athena and Artemis just doesn't seem reasonable, and that assumes that it works.

A main feature of Mac OS X is that it is highly controlled. Binary compatibility should be (and usually is) no problem for a known version of OS X. Thus, the fact that MacPorts EVER installs from source is really hard for me to understand -- this is exactly the case where it is least necessary. That demeter requires 3 separate C compilers to be installed (in addition to the predictable vendor-supplied compiler already available with the system) is very weird. I don't understand why this is necessary.

I've looked into using Brew or CitrusPerl, but getting modern versions of these to work with wxPerl seems challenging. I've tried to figure out what MacPorts does to install wxPerl that the others don't, but have had a difficult time figuring out where the MacPorts Portfiles actually are. Like I said, I haven't looked into this in great detail, but MacPorts is not very transparent. I'm also trying to assess using Brew (which, conveniently installs binaries, but inconveniently uses /usr/local instead of its own folder) or other options for Larch.

Suggestions on the best way to do these things would be greatly appreciated.

--Matt Newville