Created attachment 147181 [details] shar generated script for cad/elmerfem port We lost science/elmer-fem after a series of gcc updates and the disappearance of g77. In the meantime the distribution of the upstream package has changed and it is not available as individual packages anymore. I am attaching a unified cad/elmerfem port which replaces the left overs from the old elmer package: math/elmer-umfpack science/elmer-eio science/elmer-matc science/elmer-meshgen2d science/elmergrid We are now building this package very closely to what upstream suggests, with the side-effect that the individual components are configured, built and installed in chain. This sort-of works better with staging than before. The original package doesn't follow hier(7) strictly so it is installed in ${PREFIX}/elmer, just as upstream does. Unlike upstream, we use the existing ports for lapack, arpack and blas. Also tricky is that while portlint suggests we don't need to set CFLAGS and CXXFLAGS for CONFIGURE_ENV, removing them breaks the port. A final note is that we fail check-plist but the auto-package plist seems to work fine (fix/enhancements welcome).
Hello Pedro, Trying to discover why this port has a so special build mechanism (cheating with configure and build and do everything in the install target), I remarked that upstream is replacing configure by cmake, so I tried it: see the attached patch. With cmake, it configures, builds and installs cleanly, but the results are very different: - it depends on a MPI provider (depency added to net/mpich2) - the previous prefix was /usr/local/elmer, and now it installs by default under the regular /usr/local (could be changed if needed) - the two modules meshgen2d and post do not contain a CMakeLists.txt file, so that they are not built. Are they deprecated, or is it an error? Let me know what you think about it.
Created attachment 147503 [details] Patch to use cmake
Thank you Thierry! (wow) My understanding is that the official way to build is still configure. The configure build is rather fragile: the configure target doesn't generate any shared libraries and it was a huge PITA to get it to use the system blas, lapack and arpack. The cmake target is work-in-progress but several people have reported it works. It is strange that meshgen2d and post are not working, but perhaps it is consequence of the WIP state. I don't think I would miss meshgen2d (we do have meshgen2d as an independent port), but I don't know about elmer post. I think I prefer the CMake build but I see a small issue: it generates lib/libarpack.so which should cause a conflict with math/arpack. Perhaps CMake is not grabbing that dependency? FWIW, lib/libumfpack.a is a modified version of the library included in SuiteSparse so there is a conflict with that package if we choose to install it in /usr/local. I think we can remove ${PREFIX}/lib/lib*.a in the post-install target to solve that issue. All in all, the CMake build would certainly be much cleaner than configure here: if we can get it to use the system arpack instead of generating it's own I would prefer it.
Created attachment 147525 [details] New patch taking account of your remarks Thanks for your quick feedback! Actually, this port was not depending on the regular arpack, but on arpack-ng! To avoid the installation of libarpack, it's sufficient to not build the module mathlibs, but in this case, it fails because it is also looking for libparpack. ATM the port math/arpack-ng does not install this library, but I've just submitted PR ports/193810 to add this option. This new patch changes the dependencies accordingly. It also removes the static libraries conflicting with SuiteSparse. Since I was here, I also added a regression-test target, and it passes it successfully, but setting LD_LIBRARY_PATH is needed - I don't know if this is expected... Note: this patch applies against your original shar.
(In reply to Thierry Thomas from comment #4) > Created attachment 147525 [details] > New patch taking account of your remarks Great work, Thanks! > > Note: this patch applies against your original shar. I will try to upstream some of my patches and then I will merge it into mine.
Some quick notes, while I take some time to update the port: I had some contact with the authors and they are indeed in transitioning to CMake, and deprecating some tools in the process. Elmer post will be available as an independent tool. The latest CMake version is here: https://github.com/ElmerCSC/elmerfem/tree/devel BTW, since the CMake version doesn't build post, it is likely that we don't need tcl (yet).
Created attachment 147703 [details] Updated port (WIP) I added the updates to use CMake and updated the Makefile to download the code from github. It is still untested as it depends on the change in the arpack-ng dependency. I think the gmake and tcl dependencies may not be needed anymore.
Created attachment 147859 [details] Diff to fix you .shar (GitHub version) Hello Pedro, The attached patch fixes cmake's configure: note the added patches patch-matc_src_CMakeLists.txt, patch-fem_src_CMakeLists.txt and patch-elmergrid_src_CMakeLists.txt. Also note in Makefile the lines: .if !defined(MAINTAINER_MODE) CMAKE_ARGS+= -Wno-dev .endif If MAINTAINER_MODE is set, it produces a lot of warnings! This version is clearly a devel version, and your first port seems much cleaner. Anyway, this one builds cleanly, but produces a different plist: please check if this could be interesting.
Created attachment 147865 [details] Update shar file for elmerfem port Thank you Thierry! I am OK with the pkg-plist changes. I merged your changes and made some cleanups: - Changed the date to match the date in the latest commit (the checksum hasn't changed) - dropped the autoconf changes since we are using CMake now. - Drop note about ELMERHOME which is not valid anymore. - Dropped version number from shared mpich version. I don't have a fixed idea about which category this port should live in: since there was a previous port in science/ perhaps it should be there with a link to cad.
Created attachment 147866 [details] Updated shar file for elmerfem port One more cleanup: we don't need to remove the umfpack libraries anymore. BTW, ElmerGrid is not the only non-stripped executable.
A commit references this bug: Author: thierry Date: Mon Oct 6 21:48:29 UTC 2014 New revision: 370235 URL: https://svnweb.freebsd.org/changeset/ports/370235 Log: Add elmerfem. Elmer includes physical models of fluid dynamics, structural mechanics, electromagnetics, heat transfer and acoustics, for example. These are described by partial differential equations which Elmer solves by the Finite Element Method (FEM). PR: ports/193531 Submitted by: pfg Changes: head/cad/Makefile head/cad/elmerfem/ head/cad/elmerfem/Makefile head/cad/elmerfem/distinfo head/cad/elmerfem/files/ head/cad/elmerfem/files/patch-CMakeLists.txt head/cad/elmerfem/files/patch-elmergrid_src_CMakeLists.txt head/cad/elmerfem/files/patch-fem-acx_elmer.m4 head/cad/elmerfem/files/patch-fem-configure head/cad/elmerfem/files/patch-fem-src-Makefile.in head/cad/elmerfem/files/patch-fem_src_CMakeLists.txt head/cad/elmerfem/files/patch-matc_src_CMakeLists.txt head/cad/elmerfem/files/patch-post-src-elmerpost.h head/cad/elmerfem/files/patch-post-src-screensave.c head/cad/elmerfem/pkg-descr head/cad/elmerfem/pkg-plist
Created attachment 148047 [details] Updated shar file This is the latest version, fresh from github.
Hello Pedro, Could you rather send a diff, so that one can see the differences? Best regards.
(In reply to Thierry Thomas from comment #13) > Hello Pedro, > > Could you rather send a diff, so that one can see the differences? > > Best regards. No significant differences (I just bumped to the latest git revision). Let's leave it as it is, there was only on change upstream "Fixed elmerf90 scripts". I will submit an update when there's something more substantial. Thanks!
Ugh... Hi thierry ... Can we please remove these: math/elmer-umfpack science/elmer-eio science/elmer-matc science/elmer-meshgen2d science/elmergrid They are obsolete now. If you can also "svn mv" elmerfem to science and leave it only as a link from CAD that would be more consistent with the older port.
Created attachment 148049 [details] cleanups wrt to the committed version Oops ... you missed some cleanups I had made.
Created attachment 148050 [details] cleanups wrt to the committed version (oops)