Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Erlang.mk fails to retrieve dep versions, causing make rel to fail #924

Closed
artman41 opened this issue Feb 10, 2021 · 5 comments
Closed

Erlang.mk fails to retrieve dep versions, causing make rel to fail #924

artman41 opened this issue Feb 10, 2021 · 5 comments

Comments

@artman41
Copy link
Contributor

ERLANG_MK_VERSION = 579e9f3
git version 1.8.3.1
CentOS Linux release 7.7.1908 (Core)

Attempting to run make rel results in relx failing with a {badmatch, {error, enametoolong}} exception.

Modifying the escript to do erlang:error(Reason, Args) on the failure, I can see that it is using the following arguments.

rror in process <0.11292.0> with exit value:                                                                                                                                                                        
{enametoolong,                                                                                                                                                                                                       
    [{rlx_prv_assembler,copy_dir,                                                                                                                                                                                    
         ["/home/USER/gits/APP/_rel/APP/lib/setup-Unknown option: -C\nusage: git [--version] [--help] [-c name=value]\n           [--exec-path[=<path>]] [--html-path] [--man-path] [
--info-path]\n           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]\n           <command> [<args>]/src"],                   
         [{file,                                                                                                                                                                                                     
              "/home/USER/gits/relx/_build/default/lib/relx/src/rlx_prv_assembler.erl"},                                                                                                                      
          {line,291}]},                                                                                                                                                                                              
     ...

Looking in Erlang.mk, I think I can trace this to deps.mk#L662

{_, git} -> lists:keyreplace(vsn, 1, L1, {vsn, lists:droplast(os:cmd("git -C $(DEPS_DIR)/$1 describe --dirty --tags --always"))});

I fixed this by changing the line to

{_, git} -> lists:keyreplace(vsn, 1, L1, {vsn, lists:droplast(os:cmd("git --git-dir $(DEPS_DIR)/$(1)/.git describe --dirty --tags --always"))});

though I'm unsure whether git -C is only unsupported in the version I'm running.

@essen
Copy link
Member

essen commented Feb 10, 2021

What version of git?

@artman41
Copy link
Contributor Author

Hi, versions are as follows;

Erlang.mk Version: 579e9f3
git version: 1.8.3.1
OS: CentOS Linux release 7.7.1908 (Core)

@artman41
Copy link
Contributor Author

artman41 commented Oct 8, 2021

Encountered this again recently and forgot I even raised this.

Issue description is below with an alternate resolution


Building the dependencies and making a rel with a lower version of git (one that doesn't support -C) appears to corrupt the directories cloned.

Even after upgrading git, this isn't resolved.

To fix this corruption, a distclean must be done to remove the deps folder & the _rel directory must be removed.

Once this is done, re-run make deps rel with a newer version of git installed.

This will result in a successful build rather than relx complaining of enametoolong when parsing the deps during a make rel

@essen
Copy link
Member

essen commented Oct 8, 2021

Glad you got it resolved. I'm not sure there's anything that should be done here, it's likely that the issue will simply "solve itself" by just waiting. But let's keep the ticket open if that can help anyone.

@essen
Copy link
Member

essen commented May 16, 2023

Considering the move to Relx v4 and the workaround you had I'll be closing this. Thanks!

@essen essen closed this as completed May 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants