Re: meson vs. llvm bitcode files - Mailing list pgsql-hackers

From Nazir Bilal Yavuz
Subject Re: meson vs. llvm bitcode files
Date
Msg-id CAN55FZ1fWtTpcL3ytJioZWt78oMsCyV5ivKho-pO-EJzvQSWXQ@mail.gmail.com
Whole thread Raw
In response to Re: meson vs. llvm bitcode files  (Diego Fronza <diego.fronza@percona.com>)
List pgsql-hackers
Hi,

On Wed, 12 Mar 2025 at 16:39, Diego Fronza <diego.fronza@percona.com> wrote:
>
> Hi,
>
> The v7 patch looks good to me, handling the bitcode modules in a uniform way and also avoiding the hacky code and
warnings,much better now.
 
>
> A small note about the bitcode emission for generated sources in contrib, using cube as example, currently it creates
twodict entries in a list:
 
> bc_seg_gen_sources = [{'srcfiles': [seg_scan]}]
> bc_seg_gen_sources += {'srcfiles': [seg_parse[0]]}
>
> Then pass it to the bitcode_modules:
> bitcode_modules += {
>   ...
>   'gen_srcfiles': bc_seg_gen_sources,
> }
>
> It could be passed as a list with a single dict, since both generated sources share the same compilation flags:
> bitcode_modules += {
>   ...
>   'gen_srcfiles': [
>     {  'srcfiles': [cube_scan, cube_parse[0]] }.
>   ]
> }
>
> Both approaches work, the first one has the advantage of being able to pass separate additional_flags per generated
source.

I liked the current approach as it makes bitcode_modules easier to
understand but both approaches work for me as well.

One thing I noticed is that gen_srcfiles['srcfiles'] seems wrong.
gen_sources is a better name compared to gen_srcfiles. So, I changed
it to gen_sources in v4.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

Attachment

pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: Parallel safety docs for CTEs
Next
From: Antonin Houska
Date:
Subject: Re: AIO v2.5