Swarm hash of compiled contracts is dependent on compilation path

[spalladino]

Issue

Having the exact same project on two different paths yields two different swarm hashes for the same contract.

Steps to Reproduce

Set up a truffle project via truffle init and create a sample project with a small contract:

pragma solidity ^0.5.0;

contract Single {
  uint256 public value;
  constructor(uint256 x) public {
    value = x;
  }
}

Copy the same project via cp -a to a different path, and run truffle compile on both project folders, and then compare the ending of the bytecode for both of them:

~/Projects/tmp$ jq .bytecode truffle1/build/contracts/Single.json | tail -c200 
00000000900480633fa4f24514604a575b600080fd5b60506066565b6040518082815260200191505060405180910390f35b6000548156fea165627a7a7230582046c187cb0c8190f1380419de50c96cd3b50ead7d62a6db28356b11a3c2307fdd0029"
~/Projects/tmp$ jq .bytecode truffle2/build/contracts/Single.json | tail -c200 
00000000900480633fa4f24514604a575b600080fd5b60506066565b6040518082815260200191505060405180910390f35b6000548156fea165627a7a72305820821c5e2c55d7ceaa5cbc01a24c3ef3fcf69d49c80e741bb75db59c6d96e4d5090029"

Note that the ending (apparently the swarm hash) changes between them, and the only difference is their paths.

Expected Behavior

I would expect that the same contract, compiled with the same compiler version, yielded exactly the same bytecode. This is especially important now that EXTCODEHASH is around the corner, since it means that there is no unique codehash for a given contract source+compiler, but the same contract will have different codehashes depending on which path it was compiled.

My gut feeling is that this may be caused by truffle-compile passing absolute paths to solc. Perhaps using relative paths may help?

Environment

• Operating System: Ubuntu 18.10
• Truffle version (truffle version): v5.0.1 (installed globally with nvm)
• node version (node --version): v10.13.0
• npm version (npm --version): 6.4.1

[stale]

Thank you for raising this issue! It has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If you would like to keep this issue open, please respond with information about the current state of this problem.

[spalladino]

Bump! I think that moving to relative paths for truffle-compile should be a change easy to implement, and would open the door to using EXTCODEHASH in more scenarios. That said, I am not sure if just changing paths to relative ones would cut it.

[stale]

Thanks for your response! This issue is no longer considered stale and someone from the Truffle team will try to respond as soon as they can.

[eggplantzzz]

Cool, I'll try and see how we can resolve this!

[aaronmboyd]

Note that this issue has been open since 2018, on the deprecated repository here: trufflesuite/truffle-compile#77

@eggplantzzz There is an investigation and even a coded solution in the old issue for this.

[aaronmboyd]

How can we prioritise this?

[cameel]

This issue has been solved in #4119. Now the example from the description produces the same bytecode regardless of the project location.