On Thu Dec 14, 2023 at 9:16 AM CST, Andrew Dunstan wrote:

On 2023-12-13 We 15:59, Tristan Partin wrote:
> On Wed Dec 13, 2023 at 2:35 PM CST, Andrew Dunstan wrote:
>>
>> On 2023-12-12 Tu 18:02, Tom Lane wrote:
>> > "Tristan Partin" <tris...@neon.tech> writes:
>> >> The big patch here is adding support for Mac. objdump -W doesn't >> work on
>> >> Mac. So, I used dsymutil and dwarfdump to achieve the same result.
>> > We should probably nuke the current version of src/tools/find_typedef
>> > altogether in favor of copying the current buildfarm code for that.
>> > We know that the buildfarm's version works, whereas I'm not real sure
>> > that src/tools/find_typedef is being used in anger by anyone.  Also,
>> > we're long past the point where developers can avoid having Perl
>> > installed.
>> >
>> > Ideally, the buildfarm client would then start to use find_typedef
>> > from the tree rather than have its own copy, both to reduce
>> > duplication and to ensure that the in-tree copy keeps working.
>> >
>> >
>>
>>
>> +1. I'd be more than happy to be rid of maintaining the code. We >> already performed a rather more complicated operation along these >> lines with the PostgreSQL::Test::AdjustUpgrade stuff.
>
> I'll work with you on GitHub to help make the transition. I've already > made a draft PR in the client-code repo, but I am sure I am missing > some stuff.



I think we're putting the cart before the horse here. I think we need a perl module in core that can be loaded by the buildfarm code,  and could also be used by a standalone find_typedef (c.f. src/test/PostgreSQL/Test/AdjustUpgrade.pm). To be useful that would have to be backported.

I'll have a go at that.

Here is an adaptation of the find_typedefs from run_build.pl. Maybe it will help you.

--
Tristan Partin
Neon (https://neon.tech)

Attachment: find_typedefs.pl
Description: Perl program

Reply via email to