Hello Ludo, > I think it might make sense to create a new “simulation” module, and > eventually move OpenCascade there as well, WDYT? > Sure. I will create a new module and put the OpenFOAM package definition in there as the first one. > Some comments: > > > > > > + (build-system trivial-build-system) > >
> > > Did you consider using ‘gnu-build-system’? I think this would save > quite a few lines corresponding to the initial setup (set-paths, unpack, > patch-shebang, etc.), and also ensure that the final phases (strip, > compress-documentation, etc.) are run. In addition you wouldn’t need to > list all the usual build inputs (GCC, Coreutils, Make, etc.). WDYT? > I did consider both options, removing and modifying stages in the gnu- build-system or starting from scratch with the trivial-build-system. I can give the gnu-build-system option a go, reverting to the trivial- build-system if the new attempt proves too troublesome. One aspect I will need to investigate in the gnu-build-system is using the "./Allwmake" command to trigger the build process. In OpenFOAM, wmake is short for "wrapped-make" and the package has its own configuration step. In brief, it has its own sequence and does not follow the standard "./configure && make && make install" steps. Using the trivial-build-system the patch-shebang section is indeed a little extended. I found this was necessary to avoid a failure of the patch-shebang command using a simple 'find-files "."' from top-level directory. There is a scenario where sub-directories named '0', in the 'tutorials' directory, identified by the find-files command, being passed to 'patch-shebang', which should only receive files, not directories. This causes 'patch-shebang' to stop and the build fails. > > > > + ) > > + ) > > + ) > > + ) > > > > > Please listen to what ‘guix lint’ has to say about these. :-) > Interestingly, 'guix lint' let me get away with this without making comment. However, I shall condense things accordingly in the new patch. > What about wrapping the resulting binaries so that they have > ‘FOAM_INST_DIR’ set to %output? > > In fact, FOAM_INST_DIR is used in multiple places to navigate around the installed files (not just the binaries), so I think this variable may need to remain available as is. > > You could make it “if true”, thereby avoiding the need to define > $READLINE_ROOT. > > Could you elaborate on this idea a little? At the moment the test is "if file exists". > Could you send an updated patch to [email protected], where it will > , where it will > be visible in the patch tracker? > > > Aha, a new system! Best, Paul.
