make error 'abc' is not configured as a git submodule.

[Krishnakumarmohanraj]

Version

latest

On which OS did this happen?

Linux

Reproduction Steps

[Makefile.conf] CONFIG := gcc Error: 'abc' is not configured as a git submodule. To resolve this:

1. Back up your changes: Save any modifications from the 'abc' directory to another location.
2. Remove the existing 'abc' directory: Delete the 'abc' directory and all its contents.
3. Initialize the submodule: Run 'git submodule update --init' to set up 'abc' as a submodule.
4. Reapply your changes: Move your saved changes back to the 'abc' directory, if necessary. make: *** [Makefile:748: check-git-abc] Error 1

Expected Behavior

When i give make, its shows to remove abc folder and asked to do git submodule update --init, we done several times but same error again

Actual Behavior

Can you give solution for it please

[RCoeurjoly]

When you execute git submodule update --init, is there any error message?

[Krishnakumarmohanraj]

Hi, git submodule dont show any error, but once clone the submodule, and do --> make, its showing error as below

[root@coeserver yosys]# make [Makefile.conf] CONFIG := gcc Error: 'abc' is not configured as a git submodule. To resolve this:

1. Back up your changes: Save any modifications from the 'abc' directory to another location.
2. Remove the existing 'abc' directory: Delete the 'abc' directory and all its contents.
3. Initialize the submodule: Run 'git submodule update --init' to set up 'abc' as a submodule.
4. Reapply your changes: Move your saved changes back to the 'abc' directory, if necessary. make: * [Makefile:748: check-git-abc] Error 1 [root@coeserver yosys]# rm -rf abc [root@coeserver yosys]# git submodule update --init Submodule path 'abc': checked out '237d81397fcc85dd3894bf1a449d2955cd3df02d' [root@coeserver yosys]# make** [Makefile.conf] CONFIG := gcc Error: 'abc' is not configured as a git submodule. To resolve this:
5. Back up your changes: Save any modifications from the 'abc' directory to another location.
6. Remove the existing 'abc' directory: Delete the 'abc' directory and all its contents.
7. Initialize the submodule: Run 'git submodule update --init' to set up 'abc' as a submodule.
8. Reapply your changes: Move your saved changes back to the 'abc' directory, if necessary. make: *** [Makefile:748: check-git-abc] Error 1 [root@coeserver yosys]#

[rowanG077]

Do you have an old git version? It requires support of the -C flag. Try updating git.

[Krishnakumarmohanraj]

[root@coeserver yosys]# git --version git version 1.8.3.1 [root@coeserver yosys]# cat /etc/redhat-release CentOS Linux release 7.9.2009 (Core)

[RCoeurjoly]

git -C was added in git 1.8.5, https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.5.txt#L115. Can you update git to at least 1.8.5?

[salfter]

I'm running into the same problem, and I'm using git 2.44.2.

[rowanG077]

Are you sure you have the submodules?

[salfter]

Are you sure you have the submodules?

Yes. I'm trying to update my Gentoo ebuild. I've already switched it over from building from tarballs to building from Git, and the default behavior of git-r3.eclass is to recursively check out submodules.

By "zeroing out" the check-git-abc function in the makefile (replace the contents with exit 0;), I was able to get Yosys to build.

Yosys 0.41 built properly without needing to tweak the makefile. It appears something has changed from 0.41 to 0.42 that is causing this breakage.

[davekeeshan]

I see this when I download the tar.gz file from the tag (which is how spack installs releases from), from github, which isn't a git repo, when the makefile finds an empty abc/ directory, it issues the above error, but one cannot do a submodule update on a directory that is not a git repo.

[RCoeurjoly]

I see this when I download the tar.gz file from the tag (which is how spack installs releases from), from github, which isn't a git repo, when the makefile finds an empty abc/ directory, it issues the above error, but one cannot do a submodule update on a directory that is not a git repo.

In that case, I think the best way to proceed would be to download the corresponding abc from here. Then decompress into abc directory. The Makefile should be able to work on those cases, yosys and abc as git repos, and yosys and abc as tar.gz

[davekeeshan]

I see this when I download the tar.gz file from the tag (which is how spack installs releases from), from github, which isn't a git repo, when the makefile finds an empty abc/ directory, it issues the above error, but one cannot do a submodule update on a directory that is not a git repo.

In that case, I think the best way to proceed would be to download the corresponding abc from here. Then decompress into abc directory. The Makefile should be able to work on those cases, yosys and abc as git repos, and yosys and abc as tar.gz

I know what you are saying, but for me that seems to defy the purpose of a Makefile flow, if the user has to "do something" extra, you start to lose people. I personally know how to go around this, but this is a observation on general flow.

A simple fix is to set the default case to not compile abc at all, and abc is something extra. Alternatively you could put a wget/curl of the extra repo into the flow.

As a reference, I am maintaining the compile of yosys in the tool spack (also icarus, verible and verilator) and it is in this context that the compile is falling over

yosys/package.py

[RCoeurjoly]

I see this when I download the tar.gz file from the tag (which is how spack installs releases from), from github, which isn't a git repo, when the makefile finds an empty abc/ directory, it issues the above error, but one cannot do a submodule update on a directory that is not a git repo.

In that case, I think the best way to proceed would be to download the corresponding abc from here. Then decompress into abc directory. The Makefile should be able to work on those cases, yosys and abc as git repos, and yosys and abc as tar.gz

I know what you are saying, but for me that seems to defy the purpose of a Makefile flow, if the user has to "do something" extra, you start to lose people. I personally know how to go around this, but this is a observation on general flow.

A simple fix is to set the default case to not compile abc at all, and abc is something extra. Alternatively you could put a wget/curl of the extra repo into the flow.

As a reference, I am maintaining the compile of yosys in the tool spack (also icarus, verible and verilator) and it is in this context that the compile is falling over

yosys/package.py

I understand your frustration. For reference, before we were executing git clone inside the Makefile. This was change to a git submodule and better error messages, which you are seeing now.

I see in yosys/package.py you set ENABLE_ABC if there is an abc dir (if I understand the script correctly). That was exactly the solution I wanted to propose

[davekeeshan]

I understand your frustration. For reference, before we were executing git clone inside the Makefile. This was change to a git submodule and better error messages, which you are seeing now.

I see in yosys/package.py you set ENABLE_ABC if there is an abc dir (if I understand the script correctly). That was exactly the solution I wanted to propose

Thanks for the feedback.

I have been able to solve it inside the environment I was using, so I am not personally blocked by this.

I still haven't figured out how important abc is for a general build, does having it disabled as a default make more sense?

However, my comments here were more for the general case, where someone is working with the release tar file. I can see how a git checkout would work, as it is discrete and independent. However a git submodule can only be executed from inside a correctly setup git repo so don't be surprised if random people report this as a issue from now on (or hopefully they just find the content of this issue)

[nakengelhardt]

I still haven't figured out how important abc is for a general build, does having it disabled as a default make more sense?

ABC is almost mandatory for any synthesis flow, it's the only pass that can reliably map general logic to the target architecture primitives (LUTs or gates). You can still use CXXRTL and custom flows, but without ABC Yosys will be useless for the majority of users.

[whitequark]

To add to this, there is the -noabc flow for iCE40 FPGAs, but it is inferior to the ABC flow in terms of area and delay. While perhaps not useless (it does produce working netlists that run at a reasonable speed and mostly fit into the FPGA), its only real advantage is a slightly improved debugging experience (it preserves more intermediate net names), which is not worth the degraded delay/area for most users.