The installation instructions for SimSET, require the makefile to be edited in order to set some variable to point at the directory in which the source was unpacked.
What would be a clean way of doing this inside a Nix derivation?
Patches or substituteInPlace or let them fix the makefile, such that you can set the variable using an argument!
If they do the latter you could just use makeFlags to set the variable.
That was my initial thought, but according to my patchy (excuse the pun) understanding, the patch (which contains the unpack location) needs to be written before the unpack location is known, giving a chicken-or-egg problem. Hence my question.
This looks like it could work fairly simply. Thanks.
Te-he. Yes, that would be the sane approach, but given that the current version dates from 2014, I rate the chances of persuading them to fix the makefile as pretty slim.
No it doesn’t. You copy the content of the source to the buildfolder anyway (better: has already been happened when you patch), so the unpack localtion would be something like $(pwd).
PS: If possible by the license a fork made sense that would fix all those problems. A build shouldn’t care where its sources live exactly, as long as they are exactly here…
My flaky (pardon unintended pun, again) understanding is probably limiting me here:
- the place where
fetchurlputssrc - the build directory
-
$out(the place in/nix/storewhere the products end up)
How does stuff get from 1 to 2? (Are they even two distinct locations?)
What do we know about 2?
I haven’t found the exact license specification yet, but the blah-blah on their page implies that it’s pretty liberal. But … fork … this thought doesn’t inspire immediately happy thoughts.
Yes. What makes me nervous is the suspicion that their installation procedure ‘installs’ the build products in the source tree. So I’m not sure to what extent that location is used at build time or run time.
unpackPhase, which does roughly this (it does more, thiugh this is good for conceptional understanding):
cp $src .
chmod -R +w .
OK, but in general we don’t know what . (or $PWD) is at this stage, do we? At least not in a platform-independent way, IIRC. So I’d need to generate the patches at this point, and inject $PWD into them?
Of course we do know the location where we copy to in the unpack phase, or we were unable to copy to it.
And during patchPhase or configurePhase you need to patch the Makefile to have the correct configuration.
Whatever that means.
My point is that we do not know it a priori. It is something that Nix chooses for us at the the time it builds the derivation. Therefore I cannot write the patch (which is supposed to contain this location) until Nix has decided on the directory in which it is going to build. substituteInPlace seems to be the easier option.
(And, as I mentioned earlier, I fear that they might want the makefile to know this location because it is not only the build location, but also the installation location, which expectation would be violated by Nix. At which point, your fork idea is starting to look less unattractive.)
Yeah, so if its not statically known, use a dynamic patch via sed, substituteInPlace, etc.
By “patch” we usually mean any method that results in an altered sourcefile before reaching buildPhase.
If make install really “installs” into the same location as it builds in, then thats not “install” but just a regular build…
install target by convention should copy the build artifacts to a given prefix. If that does not happen, you need to manually copy relevant artifacts to $out
I know, I know … their installation instructions never mention make install, rather
After these changes have been made, you should be able to run the script “make_all.sh” at the top level of the SimSET directory structure. This script will remove any outdated object files that might exist and do a complete build. It will then create all of the symbolic links that you need to make in order to run all of the utilities.
AFAICT make_all.sh neither defines or uses anything resembling install-related features one would expect to find in a normal makefile.
OK. By ‘patch’ I meant the patch attribute you can set in mkDerivation.
Anyway, I guess I’ll have to identify the build artefacts and separate them from sources, decide what to do about the bazillion symlinks they create in the source tree which seem to be necessary to make the whole thing run, identify which bits of the source tree contain data that will be required at runtime.
Chances are that sorting out all that will make this patch irrelevant.