New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reverting change for implicit_option that happened in boost 1.59 #25

Closed
jmoraleda opened this Issue Dec 9, 2016 · 9 comments

Comments

Projects
None yet
4 participants
@jmoraleda

jmoraleda commented Dec 9, 2016

Dear Vladimir Prus. This is a follow up to your comment in (http://stackoverflow.com/questions/31921200/how-to-have-an-optional-option-value-in-boost-program-options)

implicit_option changed its behaviour in boost 1.59 so that --option_name option_value no longer works and needs to be written as --option_name=option_value. I would find it useful if the original behavior was restored and both formats worked (and the documentation changed to reflect this). Thank you.

@vprus

This comment has been minimized.

Show comment
Hide comment
@vprus

vprus Dec 21, 2016

Collaborator

Thanks for your comment. I've posted on the mailing list to seek more opinions, and will restore the previous behavior unless I hear strong arguments against it.

Collaborator

vprus commented Dec 21, 2016

Thanks for your comment. I've posted on the mailing list to seek more opinions, and will restore the previous behavior unless I hear strong arguments against it.

facebook-github-bot added a commit to facebook/folly that referenced this issue Jan 14, 2017

remove override from adjacent_tokens_only
Summary:
Our internal version of boost contains a patch that reverts the following commit to boost filesystem module:
boostorg/program_options@88dea3c

It was done due to a breaking change that disallows the use of "--key value" for implicit options, allowing only "--key=value" style syntax. Since there are too many tests to fix, and it's probably going to be reverted in the upstream as well (see below), removing the `override` keyword here to fix folly build.

boostorg/program_options#25

Reviewed By: meyering

Differential Revision: D4415347

fbshipit-source-id: c215331338b3aa218d26890a83aa0b363514fe79
@rimmartin

This comment has been minimized.

Show comment
Hide comment
@rimmartin

rimmartin Feb 1, 2017

Anything to be done about this?

My user simply won't use

--option_name=option_value

or

-ooption_value

or

--option_name="option_arg1 option_arg2"

And this also breaks from many common command line behaviors many people are familiar with including positional file input paths

rimmartin commented Feb 1, 2017

Anything to be done about this?

My user simply won't use

--option_name=option_value

or

-ooption_value

or

--option_name="option_arg1 option_arg2"

And this also breaks from many common command line behaviors many people are familiar with including positional file input paths

@jdfr

This comment has been minimized.

Show comment
Hide comment
@jdfr

jdfr Feb 22, 2017

This is also a pain point for me. I have many scripts scattered throughout several codebases that use the old "permissive" syntax, and they are broken in newer versions of Boost...

jdfr commented Feb 22, 2017

This is also a pain point for me. I have many scripts scattered throughout several codebases that use the old "permissive" syntax, and they are broken in newer versions of Boost...

@rimmartin

This comment has been minimized.

Show comment
Hide comment
@rimmartin

rimmartin Mar 10, 2017

Is there anyway to build boost dev while setting the program_options
revision back to 1.57? Or would it be incompatible?

Maybe fork and provide a way for users now stuck at 1.57 because of this module?

rimmartin commented Mar 10, 2017

Is there anyway to build boost dev while setting the program_options
revision back to 1.57? Or would it be incompatible?

Maybe fork and provide a way for users now stuck at 1.57 because of this module?

@jdfr

This comment has been minimized.

Show comment
Hide comment
@jdfr

jdfr Mar 10, 2017

A workaround from http://lists.boost.org/Archives/boost/2017/01/232272.php

template <typename T> 
struct greedy_implicit_value : public po::typed_value<T> 
{ 
  using base = po::typed_value<T>; 
  greedy_implicit_value(const T& value) : base(nullptr) 
  { 
    base::implicit_value(value); 
  } 
  bool adjacent_tokens_only() const override { return false; } 
unsigned max_tokens() const override { return 1; } 
}; 
template <typename T> 
po::typed_value* implicit_value(const T& value) 
{ 
  return new greedy_implicit_value<T>(value); 
} 

jdfr commented Mar 10, 2017

A workaround from http://lists.boost.org/Archives/boost/2017/01/232272.php

template <typename T> 
struct greedy_implicit_value : public po::typed_value<T> 
{ 
  using base = po::typed_value<T>; 
  greedy_implicit_value(const T& value) : base(nullptr) 
  { 
    base::implicit_value(value); 
  } 
  bool adjacent_tokens_only() const override { return false; } 
unsigned max_tokens() const override { return 1; } 
}; 
template <typename T> 
po::typed_value* implicit_value(const T& value) 
{ 
  return new greedy_implicit_value<T>(value); 
} 
@rimmartin

This comment has been minimized.

Show comment
Hide comment
@rimmartin

rimmartin Mar 10, 2017

Maybe I don't know where to put that;

I tried that back then but nothing happened

Where does it go?

rimmartin commented Mar 10, 2017

Maybe I don't know where to put that;

I tried that back then but nothing happened

Where does it go?

@rimmartin

This comment has been minimized.

Show comment
Hide comment
@rimmartin

rimmartin Mar 10, 2017

I did manage to build boost dev 1.64 for everything while setting the program_options to tags/boost-1.57.0

cd libs/program_options
git fetch --all --tags --prune
git checkout tags/boost-1.57.0
cd ../..

Initial tests look good

rimmartin commented Mar 10, 2017

I did manage to build boost dev 1.64 for everything while setting the program_options to tags/boost-1.57.0

cd libs/program_options
git fetch --all --tags --prune
git checkout tags/boost-1.57.0
cd ../..

Initial tests look good

@jdfr

This comment has been minimized.

Show comment
Hide comment
@jdfr

jdfr Mar 11, 2017

This is how I adapted it to my code; it works for me:

#if (BOOST_VERSION >= 105900)
  template <typename T> struct greedy_implicit_value_impl : public po::typed_value<T> {
    using base = po::typed_value<T>;
    greedy_implicit_value_impl() : base(nullptr) {}
    bool adjacent_tokens_only() const override { return false; }
    unsigned max_tokens() const override { return 1; }
  };
  template <typename T> po::typed_value<T>* greedy_implicit_value() {
    return new greedy_implicit_value_impl<T>();
  }
#else
#  define greedy_implicit_value po::value
#endif

po::options_description makeOptions() {
    po::options_description opts("options name");
    opts.add_options()
        ("option_name",
            greedy_implicit_value<double>()->implicit_value(0.0)->value_name("opt"),
            "option description")
    return opts;
}

jdfr commented Mar 11, 2017

This is how I adapted it to my code; it works for me:

#if (BOOST_VERSION >= 105900)
  template <typename T> struct greedy_implicit_value_impl : public po::typed_value<T> {
    using base = po::typed_value<T>;
    greedy_implicit_value_impl() : base(nullptr) {}
    bool adjacent_tokens_only() const override { return false; }
    unsigned max_tokens() const override { return 1; }
  };
  template <typename T> po::typed_value<T>* greedy_implicit_value() {
    return new greedy_implicit_value_impl<T>();
  }
#else
#  define greedy_implicit_value po::value
#endif

po::options_description makeOptions() {
    po::options_description opts("options name");
    opts.add_options()
        ("option_name",
            greedy_implicit_value<double>()->implicit_value(0.0)->value_name("opt"),
            "option description")
    return opts;
}
@vprus

This comment has been minimized.

Show comment
Hide comment
@vprus

vprus Jun 10, 2017

Collaborator

I've pushed a series of commits to go back to original behavior, the last one being b35e654

Collaborator

vprus commented Jun 10, 2017

I've pushed a series of commits to go back to original behavior, the last one being b35e654

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment