Обсуждение: flex/bison output wrongly created in the source directory

I was wondering if there is a reason that the flex and bison and other
generated source files end up in the source directory when doing an
out-of-tree build. Would a patch that puts those files in the build
trees be accepted?

wt

"Warren Turkal" <wturkal@gmail.com> writes:
> I was wondering if there is a reason that the flex and bison and other
> generated source files end up in the source directory when doing an
> out-of-tree build. Would a patch that puts those files in the build
> trees be accepted?

Probably not, since our intention is that those files be distributed as
part of source tarballs.

Also, since they are (or should be) architecture-independent, what's the
point?  Out-of-tree builds are intended to support building for multiple
architectures in parallel; but there's no reason to force independent
reconstructions of these common derived files.
        regards, tom lane

On Jan 9, 2008 9:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "Warren Turkal" <wturkal@gmail.com> writes:
> > I was wondering if there is a reason that the flex and bison and other
> > generated source files end up in the source directory when doing an
> > out-of-tree build. Would a patch that puts those files in the build
> > trees be accepted?
>
> Probably not, since our intention is that those files be distributed as
> part of source tarballs.

That makes sense.

> Also, since they are (or should be) architecture-independent, what's the
> point?  Out-of-tree builds are intended to support building for multiple
> architectures in parallel; but there's no reason to force independent
> reconstructions of these common derived files.

I was not building multiple builds in parallel as I thought they might
get fouled by the different builds. Since they do appear to not
change, I think they are just fine. Thanks for the help!

wt

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Also, since they are (or should be) architecture-independent, what's the
> point?  Out-of-tree builds are intended to support building for multiple
> architectures in parallel; but there's no reason to force independent
> reconstructions of these common derived files.

That's not the only reason for out-of-tree builds. Packagers often find it
easier to build out-of-tree since it means they can generate a clean diff
against the original source.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!

Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>   
>> Also, since they are (or should be) architecture-independent, what's the
>> point?  Out-of-tree builds are intended to support building for multiple
>> architectures in parallel; but there's no reason to force independent
>> reconstructions of these common derived files.
>>     
>
> That's not the only reason for out-of-tree builds. Packagers often find it
> easier to build out-of-tree since it means they can generate a clean diff
> against the original source.
>
>   

Right. We actually have to take some special steps in the buildfarm 
client script to clean up files generated in the tree by vpath builds so 
we have a clean repo on the next run.

But arguably packagers should be building from tarballs anyway rather 
than from CVS, in which case the build shouldn't put anything in the 
source tree.

cheers

andrew