Hello, On antradienis 05 Sausis 2010 03:11:02 Joey Hess wrote: > I was thinking about this problem today in the context of #541773, > and it came to me that all debhelper need was an -O option that > dh could use to pass user-supplied options to each command it runs. This > is a kind of optional option; if -O--foo is passed and a command does > not know about --foo, it just ignores it. > > Result is: > > dh build -B build --parallel 2 --foo="bar baz" > dh_auto_test -O-Bbuild -O--parallel=2 "-O--foo=bar baz" > dh_auto_build -O-Bbuild -O--parallel=2 "-O--foo=bar baz"
But so will: dh_install -O-Bbuild -O--parallel=2 "-O--foo=bar baz" dh_installdocs -O-Bbuild -O--parallel=2 "-O--foo=bar baz" dh_installman -O-Bbuild -O--parallel=2 "-O--foo=bar baz" dh_strip -O-Bbuild -O--parallel=2 "-O--foo=bar baz" etc. I mean, command line might be valid but output is not any more readable. On the contrary, it is (significantly) less readable... > DH_INTERNAL_OPTIONS is still hidden. It might make sense to say: > > make -f debian/rules override_dh_auto_build > DH_INTERNAL_OPTIONS=-O-Bbuild... iirc, DH_INTERNAL_OPTIONS is post processed in parseopts() by the program itself. So dh can't know how command line will end up nor what debhelper commands are run in overrides without some sort of feedback. I think we ask too much of the user to figure out how to combine DH_INTERNAL_OPTIONS with options passed in override. > But, since DH_INTERNAL_OPTIONS currently uses non-printable separator > characters, that's a small problem. Also, if the variable were exposed > this way it should probably be renamed. Non-printable separator is not a big problem. Options can be shell escaped and non-printable character replaced with a whitespace in the output. -- Modestas Vainius <[email protected]>
signature.asc
Description: This is a digitally signed message part.
