Make sure solc versions are not clashed

[arass]

Compiler complains about following line: _; (underscore with semicolon). The error is:

:76:10: Error: Expected primary expression. _; ^ Here's the code section: modifier alive() { if (deadContract) throw; _; } If I understand correctly, this is required for writing modifiers. The body of the method gets replaced where _ was. Also, lesser problem: it hates me having: pragma solidity ^0.4.3; at the top of the file. Let me know if it's an error on my part.

[adridadou]

Are u using the latest release (1.3.6) ? The issue is that 1.3.x release uses solc 0.3.x where your code is compatible with 0.4.x

Your best bet is to look at the config and provide the binaries for the version 0.4.4

[arass]

I pulled latest 1.4.0 tree off github (this project) and that's what I was running with.

[Nashatyrev]

@arass Try to clean your temp directory, there might be old compiler left unpacked

[arass]

Wiped the ethereumj/ethereumj-core folders (built, database-test, logs, test_db_2*). Grabbed latest of the tree (last update was 3 days ago). Swapped the updated ethereumj-core-1.4.0-SNAPSHOT.jar into my project (all other libs seemed unchanged).

Still got ":1:1: Error: Expected import directive or contract definition. pragma solidity ^0.4.3; ^ " So it still hates pragma.

Removed that and got:

:76:10: Error: Expected primary expression. _; ^ So still hates that. Did I miss something? Is there a way to pull version? EDIT: OK, found the problem, like you said, you meant Windows' temp directory. Guys, this is a HUGE no-no in Java design and deployment. You don't just deploy stuff out side of the deployment folder. Now things compile fine. Thanks! But this will cause a ton of issues for a ton of people. I recommend you rethink deployment. You should be able to just dump DLLs into a local folder and specify location. take a look at jclaim.com I did that many years ago. There are DLLs which are deployed along with the app which are used for some windows extensions. Works great. Just look at JNLP file. Or find another route. At least checksum the DLLs and make sure you don't have a dead version out there.

[Nashatyrev]

@arass We moved solc binaries from core package to a separate project so this might be a single time problem. However @cupuyc can you please make sure the solc versions will not conflict with the next solc upgrade

[cupuyc]

@Nashatyrev Bellow scenarios works fine for me:

1. Running command via terminal ./gradlew test -Dtest.single=CompilerTest then switch org.ethereum:solcJ-all:0.4.3 version to org.ethereum:solcJ-all:0.4.4 and run again. Appropriate solc version was used.

2. Switching solc version in the same line org.ethereum:solcJ-all:0.4.3 and run test CompilerTest in Idea IDE. In that case I had to press "Refresh gradle" to get solc version updated.

We can't put fix without ability to reproduce. But to improve situation we could put solc binaries to project dir, instead of temp dir.

• In project dir user can easily clean / check solc file.
• In that way we avoid possible conflicts if multiple ethereumJ instances were launched on the same machine.

Should we apply changes here? Also I remember you asked to implement select solc version at runtime. Do we need that now?

[cupuyc]

BTW solc with release 0.4.6 exists

[Nashatyrev]

I don't think putting any temp files to a project dir is a good idea (you may just running a single fat jar) M.b. it make sense to unpack binaries to a version specific directory?

[arass]

Typically one dumps all "output" of a project into 1 or 2 folders off the project folder. So that if someone needs to "clean" - they can do it in 1 shot and not have to fish for changes.

So you'll have an "out" folder which will have a folder for each environment you are deploying to (production/test). Followed by a folder per artifact.

Other approach is a "build" folder where all results of the last build go to (with any required subfolders).

Either way - I would recommend keeping all the droppings somewhere within a project.

If you wanna be "special" - give people an override, but default somewhere within a project tree. If I download another branch/label - I should NOT be clashing with other version under any circumstances. Or we'll be in "DLL HELL".

• 2 cents.