control of working directory by RunPMFECommand.sh

[ceheitsch]

With respect to issue #5 (now closed), the point was made that:

The directory change is necessary to run

./RunPMFECommand.sh pmfe-tests

However, it's far from clear why pmfe-tests needed to run every time the code is invoked. As it currently stands, it seems like it would be much better to have two separate wrapper scripts.

The first would be run only when the code is first installed locally or after updates to the code base. While the script would still need to be commented (see issue #7), a higher level of technical expertise on the user would be expected, since she is either attempting a local installation and/or has made updates to the code.

In contrast, the second script just include the commands needed to run already compiled code. It should be as simple as possible and would need to be more extensively commented.

[maxieds]

@ceheitsch
It appears that what you are requesting has already been in the wrapper script source sitting undocumented for a while.

The default run yields:

$ ./RunPMFECommand.sh pmfe-tests
   >> [PMFE-WRAPPER-SCRIPT] Changing current working directory to "/projects/rna/PMFEUpdated-2020.09.10-MDS-mschmidt34/GTDMMBSoftware2020/pmfe" ...

Whereas, we can change the default working directory for the script to whatever by running:

$ export PMFE_DATA_PATH="."
$ ./RunPMFECommand.sh pmfe
   >> [PMFE-WRAPPER-SCRIPT] Changing current working directory to "/projects/rna/PMFEUpdated-2020.09.10-MDS-mschmidt34" ...
   >> [PMFE-WRAPPER-SCRIPT] ERROR: Invalid PMFE utility binary argument type specified!
   >> [PMFE-WRAPPER-SCRIPT] SCRIPT USAGE: ./RunPMFECommand.sh <pmfe-sage|pmfe-findmfe|pmfe-parametrizer|pmfe-scorer|pmfe-subopt|pmfe-tests||make-pmfe-source> [OPT-ARGS ...]
   >> [PMFE-WRAPPER-SCRIPT] RECOGNIZED ENV SETTINGS (run `export VARNAME="value"` to set these options): 
   >> [PMFE-WRAPPER-SCRIPT]     -> $PMFE_DATA_PATH: Sets the default runtime files path directory
   >> [PMFE-WRAPPER-SCRIPT]                         (defaults to "/projects/rna/PMFEUpdated-2020.09.10-MDS-mschmidt34/GTDMMBSoftware2020/pmfe" if unset)
   >> [PMFE-WRAPPER-SCRIPT]     -> $PMFE_DEBUG:     Specifies whether to run the selected binary with gdb to view extra logs
   >> [PMFE-WRAPPER-SCRIPT]                         (set to "1" or "true" to enable)

Does this address your question?

[ceheitsch]

@maxieds Since the wrapper script is not commented, it's not possible to know what all it's doing. In particular, the current script seems to be conflating things which need to be done only when the code is recompiled (e.g. running the tests, and possibly others) with what needs to be done only to run the code.

[ceheitsch]

@maxieds It's my understanding that cmake (c.df #22) should be able to replace most of what the wrapper script is doing to compile the code. If so, this would be by far the cleanest and most robust way to get the code to compile, with the bonus that it should then work on other platforms as well.

[maxieds]

@ceheitsch
Part of what the wrapper script does is not to compile the code, though that option has been included for my own convenience right now. Since we are using a local install method, it needs to set the working paths to find the LibBoost and CGAL libraries. This needs to be done at runtime regardless of whether we are compiling the executables.

Nonetheless, I will look at CMake as an option to keep the compilation process error free for longer in the future.