[Bug]: 0.14.0 Build Error

[Dominion5254]

Following the README Dependencies and Installing instructions results in the below error after running make:

192.0 Boss/Mod/Initiator.cpp:1:9: fatal error: commit_hash.h: No such file or directory
192.0     1 | #include"commit_hash.h"
192.0       |         ^~~~~~~~~~~~~~~
192.0 compilation terminated.

Interestingly, it seems this file should exist when I look at the top of the stack trace: 0.110 Using existing ./commit_hash.h.

Build Environment:

• debian:bullseye-slim
• clboss 0.14.0 with a clean working tree

I have included the Dockerfile steps below for reference:

FROM debian:bullseye-slim AS clboss

RUN apt-get update -qq && \
    apt-get install -qq -y --no-install-recommends \
        autoconf-archive \
        automake \
        build-essential \
        git \
        libcurl4-gnutls-dev \
        libev-dev \
        libsqlite3-dev \
        libtool \
        pkg-config

COPY clboss/. /tmp/clboss
WORKDIR /tmp/clboss
RUN autoreconf -i
RUN ./configure
RUN make
RUN make install
RUN strip /usr/local/bin/clboss

These same build steps above have worked for at least the last several releases of clboss. Looking at the README, it doesn't seem anything should have changed breaking these build steps. Is there perhaps something that did change that wasn't updated in the README to get this build to work for 0.14.0?

[ksedgwic]

How is your working tree created?

• is it cloned from github w/ git?
• is it from a tarball or zip file?

From the Changelog for 0.14.0:

• Improved commit_hash.h dependencies and generation to ensure correct regeneration when the development tree is modified.
  ...
• Resolved issues with the regeneration of commit_hash.h when the development tree is altered by Git operations.

[ksedgwic]

I don't believe the build steps should have changed.

There is some confusion currently created because github creates default traballs which lack the commit_hash.h file. This file is present in the tarballs with the version in their file name. We're pursuing ways to clean this up: #244

[Dominion5254]

I was able to build 0.14.0 successfully in my Dockerfile by running ./generate_commit_hash.sh before make.

It seems to me either:

1. README should be updated to include the above step or
2. This conditional might need to be updated as it seems to assume (incorrectly?) that the commit_hash.h file exists if the git log file exists.

[ksedgwic]

strategy:
@if test -e $(srcdir)/.git/logs/HEAD; then
# use git, either generate or up-to-date
else
# came from tarball, needs to be there
fi

I'm still not clear whether the tree you are working from is checked out from git or unpacked from a tarball? Two different paths for debugging this problem ...

[chrisguida]

Ahhh @Dominion5254 I know what the problem is. In cln-startos we build clboss from a git submodule, so $(srcdir)/.git/logs/HEAD does not exist.

.git is simply a link to the parent git repo; that is, it's a file that looks like:

# cat .git
gitdir: ../.git/modules/clboss

@ksedgwic do you think there's a way to handle this case? I think a reasonable option might be to simply see if the user has git installed, then do git rev-parse HEAD if they do? then @Dominion5254 could add the parent repo's .git dir like we do for the CLN build and everything will just work?

The clboss docs already note that you need to have git installed when building from github.com, so it should be safe to assume the user has it if they are coming from the git repo.

[Dominion5254]

Thanks for jumping in @chrisguida. That makes sense and sounds like it should work. Alternatively, this does build by just running the script in the Dockerfile.

[chrisguida]

Ahh yeah, that script is already using git rev-parse HEAD. In that case the best course of action might be for us to detect if .git is a file rather than a directory, and run the generate script if so. We can probably just add that to the 2 test conditions that already exist.

[chrisguida]

@Dominion5254 this PR should allow you to remove the call to generate_commit_hash.sh, can you verify? #250

[ksedgwic]

@ksedgwic do you think there's a way to handle this case? I think a reasonable option might be to simply see if the user has git installed, then do git rev-parse HEAD if they do? then @Dominion5254 could add the parent repo's .git dir like we do for the CLN build and everything will just work?

Let me look into whether we can detect the submodule case directly ... might be simple ...
👀

[ksedgwic]

posted #250 (comment)

[ksedgwic]

@chrisguida Thank you for figuring this out!

[chrisguida]

@Dominion5254 I left you a comment here, let me know if you need further assistance: #250 (comment)