Support project files (dappfile) as per EIP 82 and project dependencies for compilation

[juanfranblanco]

For more info: ethereum/EIPs#82

• A solidity project will have a project / package file (currently named dappfile) for backwards compatibility with dapple the creators of the EIP82

  • The package file will contain the following information:

  name: dappsys
  version: 0.2.1-dev
  layout:
      sol_sources: contracts
      build_dir: build
  dependencies:
      solidity-stringutils: 1.0.0

  • Dependencies are stored in a common package folder (as per npm-modules) currently named 'dapple_packages' for backwards compatibility with dapple the creators the EIP82.
  • Contracts imports will follow the following format:

      import '../auth/enum.sol';
      import '../auth/events.sol';
      import '../auth/authority.sol';
      import 'solidity-stringsutils/StringUtils.sol';

Where local contracts are referenced using the ./ syntax and dependency packages are referenced using as the prefix the package name.

The ./ syntax is not followed by dapple packages, here it breaks the compatibility as it is a requirement by the compiler, and discussions with the solidity team.

Model Structure:

• Project class (with ProjectPackage, and Dependencies)
• Package, containing information from dappfile
• Introduce Contract, to hold import information to allow resolve from dependencies

Compilation:

A project will be initialised from a default configuration (currently hardcoded) or either dappfile.

Dependencies will be loaded from the file and the recursively from other packages, all the packages are in the same location.

When compiling, dependencies will be identified from imports. Simple pattern are they not local? (not starting with .) and located in the dependency packages.

If found then the same process of finding and resolve imports will be done for that dependency contract.

The compiler should be able to understand a mapping of a "package" together with the local path associated, as it will need to resolve local contract dependencies. This is currently resolved by replacing the import with the absolute path of the package contract.

[juanfranblanco]

The current code release is supporting this, keeping it open for issues, feedback

[juanfranblanco]

This EIP is no longer worked on