Wrapper should not require a config file

Cokemonkey11 commented 5 years ago

Would enable frotty to use two wrappers in the same directory.

Works fine for now by using all the default config values.

Cokemonkey11 commented 5 years ago

@Frotty @peq can you comment?

What does it mean for wurst jar wrapper to be used for two different jars - is this overreaching the intentions of this package?
How should the wrapper take config, if not via a config toml file?
Are any of the toml parameters useful to change without recompile? Listed below for convenience

initial_heap_size
maximum_heap_size
thread_stack_size
java_path
java_args
wurst_path
jar_name

Some potential design options:

use rust feature flags to compile like cargo build --features="wurstscript_jar" and cargo build --features="wurstsetup_jar"
~~use std::include to get the target jar at compiletime, so you can do something like cat funky | xargs -I {} bash -c "cargo build < {} && mv ./target/debug/main ./wrap_{}"~~

Cokemonkey11 commented 5 years ago

I've just tested std::inclued with stdin and it doesn't work for windows

Cokemonkey11 commented 5 years ago

Added list of existing config options

Frotty commented 5 years ago

Probably just specify the output name with the build command or something like that. The dir stuff can also be removed i think since we dont use wurstpack anymore.

Cokemonkey11 commented 5 years ago

Probably just specify the output name with the build command or something like that.

I can set that up. Is the output name the only parameter of interest?

The dir stuff can also be removed i think since we dont use wurstpack anymore.

What dir stuff? Here are the parameters:

initial_heap_size
maximum_heap_size
thread_stack_size
java_path
java_args
wurst_path
jar_name

What is and isn't needed?

@Frotty

Frotty commented 5 years ago

I can set that up. Is the output name the only parameter of interest?

The called jar and the output so we can generate multiple wrapper.

What is and isn't needed?

wurst_path seems superfluous now. and jar_name as said before

Cokemonkey11 commented 5 years ago

@Frotty Can we be more complete with the requirements?

The called jar and the output so we can generate multiple wrapper.

So you want compiletime arguments for --jar and --outfile?

wurst_path seems superfluous now.

Why superfluous? This is the location of .wurst. Do you mean that local directory is always used now?

jar_name as said before

jar_name goes into compiltime args - got it.

initial_heap_size - constant, obtained at compiletime from buildparams.toml?
maximum_heap_size - constant, obtained at compiletime from buildparams.toml?
thread_stack_size - constant, obtained at compiletime from buildparams.toml?
java_path - constant, obtained at compiletime from buildparams.toml?
java_args - constant, obtained at compiletime from buildparams.toml?
wurst_path - static, only `.` directory supported?
jar_name - constant, REQUIRED compiletime argument, not part of buildparams.toml
outfile - new. constant, REQUIRED compiletime argument, not part of buildparams.toml

Frotty commented 5 years ago

So you want compiletime arguments for --jar and --outfile?

I guess. But I can rename the output .exe myself, --jar is the important part.

Do you mean that local directory is always used now?

yes

Cokemonkey11 commented 5 years ago

@Frotty can you please answer the other 5 questions

initial_heap_size - constant, obtained at compiletime from buildparams.toml? maximum_heap_size - constant, obtained at compiletime from buildparams.toml? thread_stack_size - constant, obtained at compiletime from buildparams.toml? java_path - constant, obtained at compiletime from buildparams.toml? java_args - constant, obtained at compiletime from buildparams.toml?

Frotty commented 5 years ago

iirc the config file was made for when wurstscript.exe was used by Wurstpack. And thus I think all jvm options can be passed by user on CLI now in case they need them. As mentioned before, I don't care for those, proceed at will.

Cokemonkey11 commented 5 years ago

iirc the config file was made for when wurstscript.exe was used by Wurstpack.

And wurstpack is no longer used at all.

And thus I think all jvm options can be passed by user on CLI now in case they need them.

Because using wurstpack didn't have a meaningful way to choose the jvm options. But, users of the wurst jar wrapper can pass in args if they want to, just fine

As mentioned before, I don't care for those, proceed at will.

You don't care because they're not used by grill, nor wurst startup tool - which are the only remaining users of the wrapper. Is that right?

wurstscript / wurst-jar-wrapper

Wrapper should not require a config file #4