Does anyone use the engine with one letter command line flags?
Moderator: Moderators
Does anyone use the engine with one letter command line flags?
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.
./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.
Re: Does anyone use the engine with one letter command line flags?
Probably not used much, but why remove?
Re: Does anyone use the engine with one letter command line flags?
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.
It's probably a couple of hours of hacking to allow them though.
Re: Does anyone use the engine with one letter command line flags?
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?
Re: Does anyone use the engine with one letter command line flags?
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
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
Re: Does anyone use the engine with one letter command line flags?
4) compiling boost is a pita (which is required to build on windows, see mingwlibs)
Re: Does anyone use the engine with one letter command line flags?
@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).
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).
Re: Does anyone use the engine with one letter command line flags?
nope, i didn't use the short options. :)Does anyone use this? I'm probably going to remove them.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Does anyone use the engine with one letter command line flags?
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.
Re: Does anyone use the engine with one letter command line flags?
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 :'(
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 :'(
Re: Does anyone use the engine with one letter command line flags?
isn't this because of some fancy bash shell script which should still work after removing boost_program_options?!jK wrote:like `spring --list-co` gets autocompleted to `spring --list-co[nfig-vars]`
Re: Does anyone use the engine with one letter command line flags?
as long as the fullname version equivalent for each command exists I don't see why not
Re: Does anyone use the engine with one letter command line flags?
noisn't this because of some fancy bash shell script which should still work after removing boost_program_options?!
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.