Thread

Commits

  1. meson: Add dependencies to perl modules to various script invocations

  1. [PATCH] Missing dep on Catalog.pm in meson rules

    Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> — 2023-06-01T12:41:40Z

    Hi Hackers,
    
    While hacking on Catalog.pm (over in
    https://postgr.es/m/87y1l3s7o9.fsf%40wibble.ilmari.org) I noticed that
    ninja wouldn't rebuild postgres.bki on changes to the module.  Here's a
    patch that adds it to depend_files for the targets I culd find that
    invoke scripts that use it.
    
    - ilmari
    
    
  2. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Michael Paquier <michael@paquier.xyz> — 2023-06-01T13:11:49Z

    On Thu, Jun 01, 2023 at 01:41:40PM +0100, Dagfinn Ilmari Mannsåker wrote:
    > While hacking on Catalog.pm (over in
    > https://postgr.es/m/87y1l3s7o9.fsf%40wibble.ilmari.org) I noticed that
    > ninja wouldn't rebuild postgres.bki on changes to the module.  Here's a
    > patch that adds it to depend_files for the targets I culd find that
    > invoke scripts that use it.
    
    Nice catch!  Indeed, we would need to track the dependency in the
    three areas that use this module.
    --
    Michael
    
  3. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Tristan Partin <tristan@neon.tech> — 2023-06-01T21:16:27Z

    Could you create a variable for the file instead of calling files() 3
    times?
    
    > catalog_pm = files('path/to/Catalog.pm')
    
    -- 
    Tristan Partin
    Neon (https://neon.tech)
    
    
    
    
  4. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> — 2023-06-01T21:22:12Z

    On Thu, 1 Jun 2023, at 22:16, Tristan Partin wrote:
    > Could you create a variable for the file instead of calling files() 3
    > times?
    >
    >> catalog_pm = files('path/to/Catalog.pm')
    
    Sure, but which meson.build file should it go in? I know nothing about meson variable scoping.
    
    > -- 
    > Tristan Partin
    > Neon (https://neon.tech)
    
    -- 
    - ilmari
    
    
    
    
  5. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Tristan Partin <tristan@neon.tech> — 2023-06-02T04:06:04Z

    On Thu Jun 1, 2023 at 4:22 PM CDT, Dagfinn Ilmari Mannsåker wrote:
    > On Thu, 1 Jun 2023, at 22:16, Tristan Partin wrote:
    > > Could you create a variable for the file instead of calling files() 3
    > > times?
    > >
    > >> catalog_pm = files('path/to/Catalog.pm')
    >
    > Sure, but which meson.build file should it go in? I know nothing about meson variable scoping.
    
    Not a problem. In Meson, variables are globally-scoped. You can use
    unset_variable() however to unset it.
    
    In our case, we should add the ^line to src/backend/catalog/meson.build.
    I would say just throw the line after the copyright comment. Hopefully
    there isn't a problem with the ordering of the Meson file tree traversal
    (ie the targets you are changing are configured after we get through
    src/backend/catalog/meson.build).
    
    -- 
    Tristan Partin
    Neon (https://neon.tech)
    
    
    
    
  6. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Andres Freund <andres@anarazel.de> — 2023-06-02T13:00:28Z

    Hi,
    
    On 2023-06-01 23:06:04 -0500, Tristan Partin wrote:
    > In our case, we should add the ^line to src/backend/catalog/meson.build.
    
    src/backend is only reached well after src/include, due to needing
    dependencies on files generated in src/include.
    
    I wonder if we instead could just make perl output the files it loads and
    handle dependencies automatically that way? But that's more work, so it's
    probably the right thing to go for the manual path for now.
    
    Greetings,
    
    Andres Freund
    
    
    
    
  7. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Tristan Partin <tristan@neon.tech> — 2023-06-02T13:10:43Z

    On Fri Jun 2, 2023 at 8:00 AM CDT, Andres Freund wrote:
    > Hi,
    >
    > On 2023-06-01 23:06:04 -0500, Tristan Partin wrote:
    > > In our case, we should add the ^line to src/backend/catalog/meson.build.
    >
    > src/backend is only reached well after src/include, due to needing
    > dependencies on files generated in src/include.
    
    I was worried about this :(.
    
    > I wonder if we instead could just make perl output the files it loads and
    > handle dependencies automatically that way? But that's more work, so it's
    > probably the right thing to go for the manual path for now.
    
    I am not familar with Perl enough (at all haha) to know if that is
    possible. I don't know exactly what these Perl files do, but perhaps it
    might make sense to have some global lookup table that is setup near the
    beginning of the script.
    
    perl_files = {
      'Catalog.pm': files('path/to/Catalog.pm'),
      ...
    }
    
    Otherwise, manual as it is in the original patch seems like an alright
    compromise for now.
    
    -- 
    Tristan Partin
    Neon (https://neon.tech)
    
    
    
    
  8. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Andres Freund <andres@anarazel.de> — 2023-06-02T13:47:04Z

    Hi,
    
    On 2023-06-02 08:10:43 -0500, Tristan Partin wrote:
    > > I wonder if we instead could just make perl output the files it loads and
    > > handle dependencies automatically that way? But that's more work, so it's
    > > probably the right thing to go for the manual path for now.
    > 
    > I am not familar with Perl enough (at all haha) to know if that is
    > possible. I don't know exactly what these Perl files do, but perhaps it
    > might make sense to have some global lookup table that is setup near the
    > beginning of the script.
    
    It'd be nice to have something more general - there are other perl modules we
    load, e.g.
    ./src/backend/catalog/Catalog.pm
    ./src/backend/utils/mb/Unicode/convutils.pm
    ./src/tools/PerfectHash.pm
    
    
    > perl_files = {
    >   'Catalog.pm': files('path/to/Catalog.pm'),
    >   ...
    > }
    
    I think you got it, but just to make sure: I was thinking of generating a
    depfile from within perl. Something like what you propose doesn't quite seems
    like a sufficient improvement.
    
    
    > Otherwise, manual as it is in the original patch seems like an alright
    > compromise for now.
    
    Yea. I'm working on a more complete version, also dealing with dependencies on
    PerfectHash.pm.
    
    Greetings,
    
    Andres Freund
    
    
    
    
  9. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Tristan Partin <tristan@neon.tech> — 2023-06-02T15:13:44Z

    On Fri Jun 2, 2023 at 8:47 AM CDT, Andres Freund wrote:
    > Hi,
    >
    > On 2023-06-02 08:10:43 -0500, Tristan Partin wrote:
    > > > I wonder if we instead could just make perl output the files it loads and
    > > > handle dependencies automatically that way? But that's more work, so it's
    > > > probably the right thing to go for the manual path for now.
    > > 
    > > I am not familar with Perl enough (at all haha) to know if that is
    > > possible. I don't know exactly what these Perl files do, but perhaps it
    > > might make sense to have some global lookup table that is setup near the
    > > beginning of the script.
    >
    > It'd be nice to have something more general - there are other perl modules we
    > load, e.g.
    > ./src/backend/catalog/Catalog.pm
    > ./src/backend/utils/mb/Unicode/convutils.pm
    > ./src/tools/PerfectHash.pm
    >
    >
    > > perl_files = {
    > >   'Catalog.pm': files('path/to/Catalog.pm'),
    > >   ...
    > > }
    >
    > I think you got it, but just to make sure: I was thinking of generating a
    > depfile from within perl. Something like what you propose doesn't quite seems
    > like a sufficient improvement.
    
    Whatever I am proposing is definitely subpar to generating a depfile. So
    if that can be done, that is the best option!
    
    > > Otherwise, manual as it is in the original patch seems like an alright
    > > compromise for now.
    >
    > Yea. I'm working on a more complete version, also dealing with dependencies on
    > PerfectHash.pm.
    
    Good to hear. Happy to review any patches :).
    
    -- 
    Tristan Partin
    Neon (https://neon.tech)
    
    
    
    
  10. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Andres Freund <andres@anarazel.de> — 2023-06-09T18:43:54Z

    Hi,
    
    On 2023-06-02 10:13:44 -0500, Tristan Partin wrote:
    > On Fri Jun 2, 2023 at 8:47 AM CDT, Andres Freund wrote:
    > > Hi,
    > >
    > > On 2023-06-02 08:10:43 -0500, Tristan Partin wrote:
    > > > > I wonder if we instead could just make perl output the files it loads and
    > > > > handle dependencies automatically that way? But that's more work, so it's
    > > > > probably the right thing to go for the manual path for now.
    > > > 
    > > > I am not familar with Perl enough (at all haha) to know if that is
    > > > possible. I don't know exactly what these Perl files do, but perhaps it
    > > > might make sense to have some global lookup table that is setup near the
    > > > beginning of the script.
    > >
    > > It'd be nice to have something more general - there are other perl modules we
    > > load, e.g.
    > > ./src/backend/catalog/Catalog.pm
    > > ./src/backend/utils/mb/Unicode/convutils.pm
    > > ./src/tools/PerfectHash.pm
    > >
    > >
    > > > perl_files = {
    > > >   'Catalog.pm': files('path/to/Catalog.pm'),
    > > >   ...
    > > > }
    > >
    > > I think you got it, but just to make sure: I was thinking of generating a
    > > depfile from within perl. Something like what you propose doesn't quite seems
    > > like a sufficient improvement.
    > 
    > Whatever I am proposing is definitely subpar to generating a depfile. So
    > if that can be done, that is the best option!
    
    I looked for a bit, but couldn't find an easy way to do so. I would still like
    to pursue going towards dep files for the perl scripts, even if that requires
    explicit support in the perl scripts, but that's a change for later.
    
    
    > > > Otherwise, manual as it is in the original patch seems like an alright
    > > > compromise for now.
    > >
    > > Yea. I'm working on a more complete version, also dealing with dependencies on
    > > PerfectHash.pm.
    > 
    > Good to hear. Happy to review any patches :).
    
    Attached.
    
    Greetings,
    
    Andres Freund
    
  11. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Tristan Partin <tristan@neon.tech> — 2023-06-09T18:58:46Z

    Patch looks good to me!
    
    -- 
    Tristan Partin
    Neon (https://neon.tech)
    
    
    
    
  12. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Andres Freund <andres@anarazel.de> — 2023-06-10T03:16:33Z

    Hi,
    
    On 2023-06-09 13:58:46 -0500, Tristan Partin wrote:
    > Patch looks good to me!
    
    Thanks for the report Ilmari and the review Tristan! Pushed the fix.
    
    Regards,
    
    Andres
    
    
    
    
  13. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Andres Freund <andres@anarazel.de> — 2023-06-14T19:32:13Z

    Hi,
    
    On 2023-06-09 11:43:54 -0700, Andres Freund wrote:
    > On 2023-06-02 10:13:44 -0500, Tristan Partin wrote:
    > > On Fri Jun 2, 2023 at 8:47 AM CDT, Andres Freund wrote:
    > > > Hi,
    > > >
    > > > On 2023-06-02 08:10:43 -0500, Tristan Partin wrote:
    > > > > > I wonder if we instead could just make perl output the files it loads and
    > > > > > handle dependencies automatically that way? But that's more work, so it's
    > > > > > probably the right thing to go for the manual path for now.
    > > > > 
    > > > > I am not familar with Perl enough (at all haha) to know if that is
    > > > > possible. I don't know exactly what these Perl files do, but perhaps it
    > > > > might make sense to have some global lookup table that is setup near the
    > > > > beginning of the script.
    > > >
    > > > It'd be nice to have something more general - there are other perl modules we
    > > > load, e.g.
    > > > ./src/backend/catalog/Catalog.pm
    > > > ./src/backend/utils/mb/Unicode/convutils.pm
    > > > ./src/tools/PerfectHash.pm
    > > >
    > > >
    > > > > perl_files = {
    > > > >   'Catalog.pm': files('path/to/Catalog.pm'),
    > > > >   ...
    > > > > }
    > > >
    > > > I think you got it, but just to make sure: I was thinking of generating a
    > > > depfile from within perl. Something like what you propose doesn't quite seems
    > > > like a sufficient improvement.
    > > 
    > > Whatever I am proposing is definitely subpar to generating a depfile. So
    > > if that can be done, that is the best option!
    > 
    > I looked for a bit, but couldn't find an easy way to do so. I would still like
    > to pursue going towards dep files for the perl scripts, even if that requires
    > explicit support in the perl scripts, but that's a change for later.
    
    Took a second look - sure looks like just using values %INC should suffice?
    
    Ilmari, you're the perl expert, is there an issue with that?
    
    Tristan, any chance you're interested hacking that up for a bunch of the
    scripts? Might be worth adding a common helper for, I guess?
    
    Something like
    
    for (values %INC)
    {
    	print STDERR "$kw_def_file: $_\n";
    }
    
    seems to roughly do the right thing for gen_keywordlist.pl. Of course for
    something real it'd need an option where to put that data, instead of printing
    to stderr.
    
    Greetings,
    
    Andres Freund
    
    
    
    
  14. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Tristan Partin <tristan@neon.tech> — 2023-06-15T00:25:51Z

    On Wed Jun 14, 2023 at 2:32 PM CDT, Andres Freund wrote:
    > Hi,
    >
    > On 2023-06-09 11:43:54 -0700, Andres Freund wrote:
    > > On 2023-06-02 10:13:44 -0500, Tristan Partin wrote:
    > > > On Fri Jun 2, 2023 at 8:47 AM CDT, Andres Freund wrote:
    > > > > Hi,
    > > > >
    > > > > On 2023-06-02 08:10:43 -0500, Tristan Partin wrote:
    > > > > > > I wonder if we instead could just make perl output the files it loads and
    > > > > > > handle dependencies automatically that way? But that's more work, so it's
    > > > > > > probably the right thing to go for the manual path for now.
    > > > > > 
    > > > > > I am not familar with Perl enough (at all haha) to know if that is
    > > > > > possible. I don't know exactly what these Perl files do, but perhaps it
    > > > > > might make sense to have some global lookup table that is setup near the
    > > > > > beginning of the script.
    > > > >
    > > > > It'd be nice to have something more general - there are other perl modules we
    > > > > load, e.g.
    > > > > ./src/backend/catalog/Catalog.pm
    > > > > ./src/backend/utils/mb/Unicode/convutils.pm
    > > > > ./src/tools/PerfectHash.pm
    > > > >
    > > > >
    > > > > > perl_files = {
    > > > > >   'Catalog.pm': files('path/to/Catalog.pm'),
    > > > > >   ...
    > > > > > }
    > > > >
    > > > > I think you got it, but just to make sure: I was thinking of generating a
    > > > > depfile from within perl. Something like what you propose doesn't quite seems
    > > > > like a sufficient improvement.
    > > > 
    > > > Whatever I am proposing is definitely subpar to generating a depfile. So
    > > > if that can be done, that is the best option!
    > > 
    > > I looked for a bit, but couldn't find an easy way to do so. I would still like
    > > to pursue going towards dep files for the perl scripts, even if that requires
    > > explicit support in the perl scripts, but that's a change for later.
    >
    > Took a second look - sure looks like just using values %INC should suffice?
    >
    > Ilmari, you're the perl expert, is there an issue with that?
    >
    > Tristan, any chance you're interested hacking that up for a bunch of the
    > scripts? Might be worth adding a common helper for, I guess?
    >
    > Something like
    >
    > for (values %INC)
    > {
    > 	print STDERR "$kw_def_file: $_\n";
    > }
    >
    > seems to roughly do the right thing for gen_keywordlist.pl. Of course for
    > something real it'd need an option where to put that data, instead of printing
    > to stderr.
    
    I would need to familiarize myself with perl, but since you've written
    probably all or almost all that needs to be written, I can probably
    scrape by :).
    
    I definitely have the bandwidth to make this change though pending what
    Ilmari says.
    
    -- 
    Tristan Partin
    Neon (https://neon.tech)
    
    
    
    
  15. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Andrew Dunstan <andrew@dunslane.net> — 2023-06-16T20:20:14Z

    On 2023-06-14 We 15:32, Andres Freund wrote:
    > Hi,
    >
    > On 2023-06-09 11:43:54 -0700, Andres Freund wrote:
    >> On 2023-06-02 10:13:44 -0500, Tristan Partin wrote:
    >>> On Fri Jun 2, 2023 at 8:47 AM CDT, Andres Freund wrote:
    >>>> Hi,
    >>>>
    >>>> On 2023-06-02 08:10:43 -0500, Tristan Partin wrote:
    >>>>>> I wonder if we instead could just make perl output the files it loads and
    >>>>>> handle dependencies automatically that way? But that's more work, so it's
    >>>>>> probably the right thing to go for the manual path for now.
    >>>>> I am not familar with Perl enough (at all haha) to know if that is
    >>>>> possible. I don't know exactly what these Perl files do, but perhaps it
    >>>>> might make sense to have some global lookup table that is setup near the
    >>>>> beginning of the script.
    >>>> It'd be nice to have something more general - there are other perl modules we
    >>>> load, e.g.
    >>>> ./src/backend/catalog/Catalog.pm
    >>>> ./src/backend/utils/mb/Unicode/convutils.pm
    >>>> ./src/tools/PerfectHash.pm
    >>>>
    >>>>
    >>>>> perl_files = {
    >>>>>    'Catalog.pm': files('path/to/Catalog.pm'),
    >>>>>    ...
    >>>>> }
    >>>> I think you got it, but just to make sure: I was thinking of generating a
    >>>> depfile from within perl. Something like what you propose doesn't quite seems
    >>>> like a sufficient improvement.
    >>> Whatever I am proposing is definitely subpar to generating a depfile. So
    >>> if that can be done, that is the best option!
    >> I looked for a bit, but couldn't find an easy way to do so. I would still like
    >> to pursue going towards dep files for the perl scripts, even if that requires
    >> explicit support in the perl scripts, but that's a change for later.
    > Took a second look - sure looks like just using values %INC should suffice?
    >
    > Ilmari, you're the perl expert, is there an issue with that?
    >
    > Tristan, any chance you're interested hacking that up for a bunch of the
    > scripts? Might be worth adding a common helper for, I guess?
    >
    > Something like
    >
    > for (values %INC)
    > {
    > 	print STDERR "$kw_def_file: $_\n";
    > }
    >
    > seems to roughly do the right thing for gen_keywordlist.pl. Of course for
    > something real it'd need an option where to put that data, instead of printing
    > to stderr.
    >
    
    Unless I'm misunderstanding, this doesn't look terribly feasible to me. 
    You can only get at %INC by loading the module, which in many cases will 
    have side effects. And then you would also need to filter out things 
    loaded that are not our artefacts (e.g. Catalog.pm loads File::Compare).
    
    
    cheers
    
    
    andrew
    
    
    --
    Andrew Dunstan
    EDB:https://www.enterprisedb.com
    
  16. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Andres Freund <andres@anarazel.de> — 2023-06-16T21:16:28Z

    Hi,
    
    On 2023-06-16 16:20:14 -0400, Andrew Dunstan wrote:
    > Unless I'm misunderstanding, this doesn't look terribly feasible to me. You
    > can only get at %INC by loading the module, which in many cases will have
    > side effects.
    
    I was envisioning using %INC after the use/require block - I don't think our
    scripts load additional modules after that point?
    
    
    > And then you would also need to filter out things loaded that
    > are not our artefacts (e.g. Catalog.pm loads File::Compare).
    
    I don't think we would need to filter the output. This would just be for a
    build dependency file. I don't see a problem with rerunning genbki.pl et al after
    somebody updates File::Compare?
    
    Greetings,
    
    Andres Freund
    
    
    
    
  17. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> — 2023-06-16T22:10:26Z

    Andres Freund <andres@anarazel.de> writes:
    
    > Hi,
    >
    > On 2023-06-16 16:20:14 -0400, Andrew Dunstan wrote:
    >> Unless I'm misunderstanding, this doesn't look terribly feasible to me. You
    >> can only get at %INC by loading the module, which in many cases will have
    >> side effects.
    >
    > I was envisioning using %INC after the use/require block - I don't think our
    > scripts load additional modules after that point?
    
    I was thinking of a module for writing depfile entries that would append
    `values %INC` to the list of source files for each target specified by
    the script.
    
    >> And then you would also need to filter out things loaded that
    >> are not our artefacts (e.g. Catalog.pm loads File::Compare).
    >
    > I don't think we would need to filter the output. This would just be for a
    > build dependency file. I don't see a problem with rerunning genbki.pl et al after
    > somebody updates File::Compare?
    
    As long as mason doesn't object to dep files outside the source tree.
    Otherwise, and option would be to pass in @SOURCE_ROOT@ and only include
    `grep /^\Q$source_root\E\b/, values %INC` in the depfile.
    
    > Greetings,
    >
    > Andres Freund
    
    - ilmari
    
    
    
    
  18. Re: [PATCH] Missing dep on Catalog.pm in meson rules

    Tristan Partin <tristan@neon.tech> — 2023-06-16T22:11:59Z

    On Fri Jun 16, 2023 at 5:10 PM CDT, Dagfinn Ilmari Mannsåker wrote:
    > Andres Freund <andres@anarazel.de> writes:
    >
    > > Hi,
    > >
    > > On 2023-06-16 16:20:14 -0400, Andrew Dunstan wrote:
    > >> Unless I'm misunderstanding, this doesn't look terribly feasible to me. You
    > >> can only get at %INC by loading the module, which in many cases will have
    > >> side effects.
    > >
    > > I was envisioning using %INC after the use/require block - I don't think our
    > > scripts load additional modules after that point?
    >
    > I was thinking of a module for writing depfile entries that would append
    > `values %INC` to the list of source files for each target specified by
    > the script.
    >
    > >> And then you would also need to filter out things loaded that
    > >> are not our artefacts (e.g. Catalog.pm loads File::Compare).
    > >
    > > I don't think we would need to filter the output. This would just be for a
    > > build dependency file. I don't see a problem with rerunning genbki.pl et al after
    > > somebody updates File::Compare?
    >
    > As long as mason doesn't object to dep files outside the source tree.
    > Otherwise, and option would be to pass in @SOURCE_ROOT@ and only include
    > `grep /^\Q$source_root\E\b/, values %INC` in the depfile.
    
    Meson has no such restrictions.
    
    -- 
    Tristan Partin
    Neon (https://neon.tech)