Decompile Problems: Forge installer OSX 10.5.8 / astyle [solution]

[thelatemrb]

Frankly, I'm not sure if osx 10.5.8 is any good for coding against forge. It's old now and the installation process for forge means that you may have issues getting python and java set up properly in order to run the forge installer. There are posts elsewhere that cover setting up java and getting the right version of python.

 

Trying to set up forge failed for me with issues around the script failing at the decompile stage. The problems centred around the astyle program used by the installer. To solve the issues I installed a new version of astyle, and changed some options the forge's configuration file/s for astyle.

 

The forge setup package comes with astyle - you can find the osx version of it on your system here: forge/mcp/runtime/bin/astyle-osx

 

Download astyle from sourceforge and follow the installation instructions on the site to 'make' it on your own machine.

Once done building your new version of astyle, rename it to astyle-osx and replace the original in forge/mcp/runtime/bin/ with your new one.

 

Once I re-ran forge's install.sh it produced another issue, still failing to decompile.

The mcp.log file said that one of the options for astyle (from forge's config files) was invalid.

The option in question was max-instatement-indent=2

I checked the online documentation for astyle, and it seems that the option should be valid, but running the command astyle-osx -h (help) (with the new version of astyle on my machine) gave the info that the minimum this option can be set to is actually 40.

 

Looking through the forge directories, I found 2 instances of config files for astyle (called astyle.cfg)  - one in forge/fml/conf/ and one in forge/mcp/conf/.

I changed the value for the option to 40 (i.e. max-instatement-indent=40 instead of max-instatement-indent=2), and re-ran forge's install.sh script ; this time it ran through to completion.

 

This might just have been be a problem on my particular setup, but if not, I hope this solution helps someone else.

 

(This was originally a response to another post, it's since been rewritten to make more sense standing alone at the top of this thread)

[luacs1998]

Pastebin your mcp.log. Walls of text don't help without logs.

[thelatemrb]

Hi, not sure what you want my logs for, my post wasn't a cry for help.

I had gotten to the same sticking point as a previous poster, and since nobody had responded to them with a resolution, I posted the actions that had resolved mine.

 

Has the original thread been removed?

 

Is there a special mechanism for offering possible solutions? If so let me know and I'll not pollute threads with my walls of text.

[SanAndreaP]

Hi, not sure what you want my logs for, my post wasn't a cry for help.

I had gotten to the same sticking point as a previous poster, and since nobody had responded to them with a resolution, I posted the actions that had resolved mine.

 

Has the original thread been removed?

 

Is there a special mechanism for offering possible solutions? If so let me know and I'll not pollute threads with my walls of text.

 

I suggest to change the title a bit, it's misleading. Maybe append " - Solution" to it?

[thelatemrb]

Fair enough - sounds like good advice.

 

Thing is, my post was a reply on a pre-existing thread. I don't know what's happened to the original, but my post is now the start of this thread. So I just assumed that a moderator had moved my post into a new thread and titled it.

Also, within the context of the original thread - it was only a possible solution - so I didn't want to make out that it was anything more than a solution to an apparently similar probelm I'd had.

 

Thanks for the sound advice though - I'll go and take a look and see how to modify the thread/topic title and maybe rewrite the post see that it's a bit clearer (now that it isn't a response to anything).

 

 

[smbarbour]

I had this same issue on one of my Linux machines.  The real question though is why is this value being set so low?  The default setting is 40, and "A maximum of less than two indent lengths will be ignored."  Since the indent length is not being specified in the config, the indent length is 4 spaces.

 

According to the astyle documentation, this is, in fact, an invalid configuration.

[LexManos]

For 1, that means that a value of  >2 will be ignore, not of >=2. There is a difference.

For 2, this is odd, if that is indeed the case that means all of our code should be wrapped around 8 character columns, either way, the specification doesn't state that the minimum is 40. It says the default is 40.

This is just one of the many astyle differences we have to deal with cross OS's. Forge actually has a second styler it runs over the code to fix these discrepancies.

 

Anyways this is interesting i'll pass it tot he MCP team to change the deault, curious why only a few people are having issues. I blame  different astyle versions. As long as your set the one included with MCP to runnable, it should work fine.

[apoc]

I just experienced exactly the same problem as thelatemrb, the solution worked for me.

 

I'm on a Debian Linux box with astyle 2.03, and no wine. Its a x86_64 server environment and I don't want to install x86 multilib (32bit-wine) for that, it would be great if that could be fixed! I never had that problem before, on OpenSuse I've got wine installed and that just worked.

 

== Reformating client ==
> Cleaning sources
> Replacing OpenGL constants
> Reformating sources
'astyle --suffix=none --quiet --options=conf/astyle.cfg src/minecraft/*.java src/minecraft/net/minecr...' failed : 1
Decompile failed

 

/edit looks like forge already fixed it, but mcp (8.04) not