[MacPorts] #35342: Submission: sundials

[MacPorts]

#35342: Submission: sundials
--------------------------+--------------------------------
  Reporter:  jjstickel@…  |      Owner:  macports-tickets@…
      Type:  submission   |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  sundials     |
--------------------------+--------------------------------

Comment (by sean@…):

 Replying to [comment:25 jjstickel@…]:
 > That discussion is beyond me. I hope that this port can be committed and
 then adjusted appropriately based whatever is decided for mpi.

 [[BR]]
 Sure, but it makes a simple portfile. Though I'm not opposed to adding
 sundials before that decision.

 > > * you don't need the destdir patch if you build with cmake
 > OK, but I can't seem to make sundials compile shared libraries with
 cmake, and it seems that the developers of Sundials consider cmake to be a
 secondary build system (see INSTALL_NOTES from the Sundials sources).

 [[BR]]
 Yes, Carol hasn't given cmake much love but it does indeed work.

 > > * you'll probably to fix the use of install_name_dir (you can check
 this by using 'otool -L /opt/local/lib/*sundial*.dylib
 > Not sure what you mean here -- is this in reference to using cmake for
 building?

 [[BR]]
 Yep. You can see my version of the portfile
 [https://bitbucket.org/seanfarley/scienceports/src/2832e9d9716e178f20b5ab0eb563f40d7fcce730/math/sundials/Portfile?at=default
 here].

 > > * you no longer need the depends_lib for the compilers
 > I presume that you mean the depends_lib-append may be changed to
 depends_build-append for the compilers?

 [[BR]]
 Actually, you can get rid of the line altogether since MacPorts 2.2
 handles it in base.

 > > * your g95 variant will certainly give you problems with your mpich
 and openmpi variants since neither of those ports have a g95 variant
 > It looks like openmpi has a g95 variant, but mpich does not. I can add a
 conflict for g95 to +mpich, if you think that is sufficient.

 [[BR]]
 I would say just get rid of it entirely unless you really need an
 interface built with g95?

 > > * you really don't need a static variant, imo; sundials will install
 the static libraries along side the shared ones
 > I can easily remove this variant.

 [[BR]]
 Yeah, it simplifies things greatly.

 > > * (other devs take note) can we please not set the atlas variant as
 default on ports that are designed for sparse linear algebra?
 > I don't follow, but I can remove this default variant.

 Sundials is a suite of time-stepping methods (well, just two, really:
 Adams-Moulton and BDF) with a default JFNK (Jacobian Free Newton-Krylov)
 iterative method. You can use a dense (direct) solver for a single
 processor but using that for multiple processors is unsupported since the
 bulk of Sundials users are in the sparse matrix world (aka, iterative
 methods). ATLAS is an automatically tuned, dense linear algebra package.
 Hence, you will see practically no speed up by linking Sundials with
 ATLAS. Hence, I am opposed to having it be the default variant. I don't
 even think it should be a variant at all but I could be convinced
 otherwise.

-- 
Ticket URL: <https://trac.macports.org/ticket/35342#comment:26>
MacPorts <http://www.macports.org/>
Ports system for OS X