Formaline fails for trying to remove non-existent file

Create issue
Issue #2236 open
Steven R. Brandt created an issue

I removed exe/cactus_icc and tried to rebuild. Formaline blocks me.

Formaline: ERROR during: Removing file from git repo
Command was: /usr/bin/git --git-dir='/ddnA/project/sbrandt/chemora/Cactus/configs/icc/configjar.git/.git' update-index --force-remove '/icc/BUILD-ID' at /ddnA/project/sbrandt/chemora/Cactus/configs/icc/scratch/Formaline/bin/update-git-repo.pl line 60, <STDIN> line 5257.
make[1]: *** [/ddnA/project/sbrandt/chemora/Cactus/configs/icc/build/Formaline/git-store-source] Error 2
make[1]: *** Waiting for unfinished jobs....

Comments (12)

  1. Roland Haas

    Can you provide more of the log output, please? The file exe/cactus_icc itself is not stored in Formaline's git repository, so the one it tries to remove is another one.

  2. Roland Haas

    Looks like some bash variable is not set and a like like "$CONFIGS_DIR/icc/BUILD-ID" ended up being "/icc/BUILD-ID".

  3. Roland Haas

    Sorry I did not want to claim that it is exactly a line that looks like that or that the variable is named CONFIGS_DIR, just that errors like this (trying to access a file in "/") are usually caused by this type of issue. Note that I cannot reproduce this using the current candidate for the Proca release.

  4. Steven R. Brandt reporter

    I'll work on reproducing shortly (I deleted the configs dir and started over). I suspect it has something to do with not naming my config "sim," but I'm not sure.

  5. Steven R. Brandt reporter

    OK, currently this issue is preventing me from building on Shelob/Supermike. After digging in a little, I find that the problem is at least partly an issue with CACTUS_CONFIGS_DIR and CONFIGS_DIR. The main Cactus makefile sets CONFIGS_DIR to CACTUS_CONFIGS_DIR if CACTUS_CONFIGS_DIR is set.

    Formaline, however, sets CACTUS_CONFIGS_DIR ?= $(CCTK_HOME)/configs in Formaline/src/make.configuration.deps. For some reason which I can't understand, CACTUS_CONFIGS_DIR is set to empty when it gets to this point. However, it seems to me, that all references to CACTUS_CONFIGS_DIR in Formaline/src/make.configuration.deps ought to instead refer to CONFIGS_DIR, which it should simply expect to be set.

    When I make this change, unfortunately, I get the following error:

    Thorns_Diagnostics/particle_tracerET ExternalLibraries/pthreads WVUThorns_Diagnostics/smallbPoynET ExternalLibraries/zlib
    Formaline: Committing source tree to git repository...
    Formaline: Created git tag build-icc-shelob1.hpc.lsu.edu-sbrandt-2019.03.19-16.14.53-21958
    Formaline: Updated git branch config-icc-shelob1.hpc.lsu.edu-ddnA-project-sbrandt-chemora-Cactus
    Formaline: Pushing to master git repository...
    Formaline: Pushing to local git repository /ddnA/project/sbrandt/chemora/Cactus/../CactusSourceJar.git...
    Formaline: ERROR during: Pushing to local git repository
    Command was: /usr/bin/git --git-dir='/ddnA/project/sbrandt/chemora/Cactus/cactusjar.git/.git' push -v -f --all '/ddnA/project/sbrandt/chemora/Cactus/../CactusSourceJar.git' at /ddnA/project/sbrandt/chemora/Cactus/configs/icc/scratch/Formaline/bin/update-git-repo.pl line 60.
    make[1]: *** [/ddnA/project/sbrandt/chemora/Cactus/configs/icc/build/Formaline/git-store-source] Error 25
    make[1]: *** Waiting for unfinished jobs....
    
  6. Roland Haas

    If this depends on setting CACTUS_CONFIGS_DIR by the user (or having configs somewhere other than Cactus/configs) then I am tempted to downgrade to “minor” since it would not seem to require attention beore the next release.

    About Formaline’s setting of CACTUS_CONFIGS_DIR, as far as I can tell it should best not do any such thing and instead use CONFIGS_DIR which the main Cactus Makefile exports to make available to sub-makes.

  7. Roland Haas

    @Steven R. Brandt this is marked as “major” (by you) so it must be addressed (one way or the other) before the next release. So far you are the only person who was able to observe the failure (not too surprising given that it may depend on the exact state of the make system).

    Do you have a way to reproduce this? Do you think this needs to remain set to “major” bug or can be downgraded to “minor” since it is not something that would prevent the release from happening?

  8. Log in to comment