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

build project error #539

Closed
13 of 25 tasks
tututt opened this issue Sep 17, 2018 · 8 comments
Closed
13 of 25 tasks

build project error #539

tututt opened this issue Sep 17, 2018 · 8 comments
Labels
exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up

Comments

@tututt
Copy link

tututt commented Sep 17, 2018

Pre-check

  • This is not a IPFS Cluster website content issue (file those here)
  • I read the troubleshooting section of the website and it did not help
  • I searched for similar issues in the repo without luck
  • All my peers are running the same cluster version
  • All my peers are configured using the same cluster secret

Basic information

  • Version information (mark as appropiate):
    • Master
    • Release candidate for next version
    • Latest stable version
    • An older version I should not be using
  • Type (mark as appropiate):
    • Bug
    • Feature request
    • Enhancement
  • Operating system (mark as appropiate):
    • Linux
    • macOS
    • Windows
    • Other: which?
  • Installation method (mark as appropiate):
    • Binaries from dist.ipfs.io
    • Built from sources
    • Docker
    • Snap
    • Other: which?

Description

I build ipfs-cluster:
go into ipfs-cluster folder,and "make all",then meet that "# github.com/ipfs/ipfs-cluster/api
../../go/src/github.com/ipfs/ipfs-cluster/api/types.go:191:6: cannot use c (type cid.Cid) as type *cid.Cid in field value
../../go/src/github.com/ipfs/ipfs-cluster/api/types.go:258:6: cannot use c (type cid.Cid) as type *cid.Cid in field value
../../go/src/github.com/ipfs/ipfs-cluster/api/types.go:805:12: cannot assign cid.Cid to ref (type *cid.Cid) in multiple assignment
../../go/src/github.com/ipfs/ipfs-cluster/api/types.go:812:6: cannot use c (type cid.Cid) as type *cid.Cid in field value"
and go to "go-cid" project , find that type mismatch,i think go-cid version is run. How to do with it

@hsanjuan
Copy link
Collaborator

Please read the documentation: https://cluster.ipfs.io/documentation/download/#installing-from-source .You should run make install or make build. make all assumes your dependencies are rewritten already.

@hsanjuan hsanjuan reopened this Sep 18, 2018
@hsanjuan
Copy link
Collaborator

Sorry, I was too harsh here. make all should not fail like this and it's not very nice that it does. We'll fix it!

@hsanjuan hsanjuan added kind/bug A bug in existing code (including security flaws) help wanted Seeking public contribution on this issue exp/novice Someone with a little familiarity can pick up P1 High: Likely tackled by core team if no one steps up labels Sep 18, 2018
@tututt
Copy link
Author

tututt commented Sep 19, 2018

@hsanjuan,i have a suggestion, it is better to use package which same as the package on github.

@hsanjuan
Copy link
Collaborator

@tututt what do you mean?

@tututt
Copy link
Author

tututt commented Sep 19, 2018

@hsanjuan Now in ipfs-cluster project, it import package like this: ""github.com/ipfs/go-ipfs-cmdkit/files"", after "make install", it change to "manet "gx/ipfs/QmV6FjemM1K8oXjrvuq3wuVWWoU2TLDPmNnKrxHzY3v6Ai/go-multiaddr-net". Why use the first one package

@hsanjuan
Copy link
Collaborator

@tututt we use gx to fix our dependencies. Gx works by rewriting import paths to those of the fixed dependency. go-ipfs-cmdkit will be rewritten into something else, and probably placed in a different line as before (because of gofmt).

This allows to be sure that the project can always be built. Something that does not always work without rewriting (like right now, because how the cid package changed upstream).

@tututt
Copy link
Author

tututt commented Sep 20, 2018

@hsanjuan OK, I see

kishansagathiya added a commit to kishansagathiya/ipfs-cluster that referenced this issue Sep 20, 2018
`make all` assumes that your dependencies are re-written. This can lead
to unexpected failures/errors.
This commit changes `make all` to update dependencies as well.

License: MIT
Signed-off-by: Kishan Mohanbhai Sagathiya <kishansagathiya@gmail.com>
kishansagathiya added a commit to kishansagathiya/ipfs-cluster that referenced this issue Sep 21, 2018
`make all` assumes that your dependencies are re-written. This can lead
to unexpected failures/errors.
This commit changes `make all` to update dependencies as well.

License: MIT
Signed-off-by: Kishan Mohanbhai Sagathiya <kishansagathiya@gmail.com>
kishansagathiya added a commit to kishansagathiya/ipfs-cluster that referenced this issue Sep 21, 2018
`make all` assumes that your dependencies are re-written. This can lead
to unexpected failures/errors.
This commit changes `make all` to update dependencies as well.

License: MIT
Signed-off-by: Kishan Mohanbhai Sagathiya <kishansagathiya@gmail.com>
@kishansagathiya
Copy link
Contributor

Resolved with a611190

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/novice Someone with a little familiarity can pick up help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up
Projects
None yet
Development

No branches or pull requests

3 participants