Formaline should also work with globally installed simfactory

Create issue
Issue #1108 closed
Frank Löffler created an issue

Currently, Formaline doesn't find a globally installed simfactory. The build succeeds, but produces error messages close to the end like

sh: 1: /home/knarf/Cactus/bin/sim: not found

The attached patch tries, after not finding 'sim' in that location simply 'sim' - to be searched for in the users' search path. It also redirects stderr of the first (but not second) try to /dev/null to avoid these error messages. It doesn't do this for the second try to make sure the users sees 'something' which points towards Formaline not finding something.


Comments (17)

  1. Erik Schnetter
    • removed comment

    I'd prefer a patch that first determines the location of a working "sim" command, and then uses this in all later commands.

    The current patch uses "|" instead of

    , i.e. it pipes the output of sim into another sim command.

  2. Roland Haas
    • removed comment

    We could also make the location of simfactory as well as the location of the machine-global formaline jar somehthing that can be set via option list options (a la HDF5_DIR) rather than hard-coding this (or some clever logic) into the formaline make system/perl scripts. I would prefer that option (as well as the option of not having a machine global repository eg on a Kraken where I am usually close to my quota in $HOME and would have to put the extra formaline jar into $SCRATCH [which defeats the purpose]).

  3. Erik Schnetter
    • removed comment

    This is a good idea.

    Also, if one uses Simfactory to configure, then it should already know its location, and pass it on to Cactus.

  4. Erik Schnetter
    • removed comment

    Formaline uses Simfactory to determine the sourcebasedir. If found, it creates a global git repository there, containing the source trees from all Cactus configurations found on this machine.

    Another potential use (not yet implemented) would be to obtain a canonical machine name, since the host names are often specific to the front-ends or compute nodes on which things are running, and may even be identical for different systems (e.g. Kraken/Hopper).

  5. Frank Löffler reporter
    • removed comment

    Isn't sourcebasedir usually ${CCTK_HOME}/.. ? ${CCTK_HOME} is known to Formaline.

  6. Erik Schnetter
    • removed comment

    $CCTK_HOME is sourcedir, the directory containing the source tree. sourcebasedir is the directory containing all the source trees, probably the equivalent of $CCTK_HOME/..

  7. Frank Löffler reporter
    • removed comment

    Yes, that is what I wrote. Could we make Formaline use ${CCTK_HOME}/.. instead of calling simfactory? This would have the benefit that it would actually work without simfactory.

  8. Frank Löffler reporter
    • removed comment

    The one where simfactory 'tells' Formaline where to find it? And then combine this with a fallback to ${CCTK_HOME}/..?

  9. Roland Haas
    • removed comment

    One minor thing: using `${CCTK_HOME}/..` can lead to unexpected behavior if `$CCTK_HOME` is a symbolic link (not quite sure why it would be set up like this, but it might) I think. Should work otherise. I *would* prefer having an option of overriding this (eg. when building cactus-source from Formaline or when I have Cactus trees in odd places).

  10. Frank Löffler reporter
    • removed comment

    I agree that there could be a way to overwrite what Formaline uses as directory to store the repos by default. Please open a ticket for that. However, the current problem is that it doesn't work at all if simfactory is installed globally (and/or is locally installed but unused and thus, not configured).

    I suggest to modify the current patch to use ${CCTK_HOME}/.. as repo path and not to look for simfactory at all. Another issue should then be opened to make it possible to change this path via an option which then simfactory can use, or a user can set.


  11. Ian Hinder
    • removed comment

    Unnecessary coupling is usually bad. If Formaline can obtain the information it needs from Cactus without assuming that the user is using SimFactory, then I'm all for it.

  12. Log in to comment