Hello,
I had some trouble posting to the list, so I'm not sure if my previous message got through or not. I apologise if it has. Anyway, it appears that this has not been tested on Windows/MinGW as it currently does not work. Everything worked fine with the old progname module. A sample build log is here: https://ci.appveyor.com/project/fontforge/fontforge/build/1.0.32 Thanks, Jeremy ________________________________ From: bug-gnulib <bug-gnulib-bounces+jtanx=outlook....@gnu.org> on behalf of Jim Meyering <j...@meyering.net> Sent: Tuesday, 6 September 2016 12:47 PM To: Pino Toscano Cc: bug-gnulib@gnu.org List Subject: Re: [PATCH v2 0/4] New getprogname module On Mon, Sep 5, 2016 at 9:22 AM, Jim Meyering <j...@meyering.net> wrote: > On Mon, Sep 5, 2016 at 7:28 AM, Pino Toscano <ptosc...@redhat.com> wrote: >> On Saturday, 3 September 2016 20:47:15 CEST Jim Meyering wrote: > ... >> Another thing: should some deprecation warning/note be added regarding >> the progname module? > > I like the idea of adding a deprecation warning. > If it could be completely replaced, I'd suggest to add the "Status: > deprecated" attribute to its modules file, but we don't have a > replacement for set_program_name, so there may still be legitimate > uses. If a future change were to move set_program_name into its own > new module, *then*, we could officially deprecate the progname module. > >> Is NEWS the proper place for them? Attached there >> is a small documentation addendum. > > Good idea. > While this is not officially an incompatible change, converting is > invasive enough that this NEWS blurb belongs in that section. > > I've split a long sentence and merged that into your first commit. > And pushed. > >>> I'm prepared to push the attached, but will wait for your ack. > > If you're interested, one more thing that may help avoid trouble would > be to add a syntax-check rule to prohibit new uses of this module, > including new inclusion of progname.h, new declarations of > program_name or anything else you can think of that should no longer > be done here in gnulib. FYI, while adapting grep to use this module, I encountered a single new error/warning. The attached patch fixes that:
