flex/bison output wrongly created in the source directory

"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