Does anyone use the engine with one letter command line flags?

[hokomoko]

Apparently instead of
./spring --game "Test Game"
you can do
./spring -g "Test Game"

and similarly there are other flags with a one letter alias available.

Does anyone use this? I'm probably going to remove them.

[gajop]

Probably not used much, but why remove?

[hokomoko]

because gflags (the alternative to boost::program_options that I've found) doesn't support them out of the box.
It's probably a couple of hours of hacking to allow them though.

[gajop]

In that case I would like them to remain if it's not too much work for you. Did we use getopt or was it boost::program_options, and if so, why the change?

[hokomoko]

boost::program_options
The change is since I'm working on getting rid of boost in the engine.
currently the only two things remaining in the repo (not including tests) are boost::regex which can be replaced std::regex after we upgrade to g++ >= 4.9 and boost::unordered_multimap which will need a replacement.

Why is this good to remove boost dependency?
1) if you'll check travis clang build times (Which don't use cache), they are now down by half or so.
2) boost dep is a huge pain to setup on windows
3) debug build sizes are considerably smaller, the zipped versions on the site that are used for the translator are ~20% smaller

[abma]

4) compiling boost is a pita (which is required to build on windows, see mingwlibs)

[zwzsg]

Couple monthes ago I implemented a GetOpt in C:
GetOpt.c
GetOpt.h

[gajop]

@hoko/@abma
Thanks for the explanation, sounds reasonable.
Boost used to be very high quality (albeit difficult to use), which is probably why a lot of it (at least API wise) ended up being in the C++11 standard, so I'm surprised to see it being this bad performant, even if it's just the compilation.
Anything that makes compilation faster is always welcome, but hopefully you can still make it backwards compatible (seeing as you aren't making a claim that short options are bad design wise).

[abma]

Does anyone use this? I'm probably going to remove them.

nope, i didn't use the short options. :)

[Silentwings]

I guess the only thing that causes long compile times in boost is its size and complexity, afaik it is still a very high quality set of libraries and the semi-official preview of whats to come in future C++ standards. Seems a shame to lose access to it.

[jK]

D:

so i am the only one who misses all the fancy boost cmdline features?
like `spring --list-co` gets autocompleted to `spring --list-co[nfig-vars]`


RIP then :'(

[abma]

like `spring --list-co` gets autocompleted to `spring --list-co[nfig-vars]`

isn't this because of some fancy bash shell script which should still work after removing boost_program_options?!

[smoth]

as long as the fullname version equivalent for each command exists I don't see why not

[jK]

isn't this because of some fancy bash shell script which should still work after removing boost_program_options?!

no

The bashcomp systems so far don't try to get the available args, esp. cause there is no standard how to get them nor how to parse them. Also when you would just execute `myprogram -h` it's possible that the program doesn't handle the `-h` at all and just starts the program. Okay, today you could execute it in a sandbox/docker env to prevent any evil side effects, still it's nasty.

That's why gentoo comes with around 200 baschcomp scripts/configs.