public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andres Freund <[email protected]>
To: Anton A. Melnikov <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: .bc files build dependency issues.
Date: Mon, 30 Mar 2026 08:39:23 -0400
Message-ID: <7ihq6kmoruqicq5qqns3wicb4yydrqgy4iqvke3wafa5f2h6i4@5y4pwfuogh2y> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
Hi,
On 2026-03-30 10:28:30 +0300, Anton A. Melnikov wrote:
> While the original discussion was about a specific commit
> ecaf7c5df and related fix in 16492df7 for 16+
> and its effects [1], i would like to point out that
> a similar behavior can be observed
> on earlier stable branches (REL_14/15_STABLE) as well.
> Using a pre-built source tree and the following reproduction
> that is slightly modified version from [2] which suggests
> that this is a known pattern for exposing the issue:
>
> cd src/backend/parser
> rm -rf .deps/ gram.c scan.c *.o *.bc gram.h
> make parser.bc
IOW, if you do something that intentionally breaks things, things break.
> result in:
>
> $ make parser.bc
> /usr/lib/llvm-16/bin/clang -Wno-ignored-attributes -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Xclang
> -no-opaque-pointers -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-deprecated-non-prototype
> -O2 -I. -I. -I../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/local/include -flto=thin -emit-llvm
> -c -o parser.bc parser.c
> In file included from parser.c:25:
> ../../../src/include/parser/gramparse.h:29:10: fatal error: 'parser/gram.h' file not found
> #include "parser/gram.h"
> ^~~~~~~~~~~~~~~
> 1 error generated.
> make: *** [../../../src/Makefile.global:1084: parser.bc] Error 1
>
> Since this can be reproduced reliably on REL_14/15, it seems worth asking
> whether fix for .bc files (or something equivalent) should also be
> backpatched to lower branches, instead of only applying to newer ones.
This seems like a complete non-issue to me. What is the actual problem here?
You intentionally removed dependency information. You intentionally removed
part of the generated files, but not all of them.
> Also as a possible improvement perhaps make the fix less strictly?
> I.e. replace each .bc file's dependency on all .o files
> with a more weak dependency just on all source .c files.
> Namely use:
>
> $(patsubst %.o,%.bc, $(OBJS)): $(patsubst %.o,%.c, $(OBJS))
>
> instead of:
>
> $(patsubst %.o,%.bc, $(OBJS)): $(OBJS)
>
> This might still preserve correct build ordering while reducing
> unnecessary coupling between targets.
It'd also be broken if one of the source files is built from c++, for example.
> As a result make will run faster during parallel builds since it won't wait
> for absolutely all the object files to be created.
>
> For example, rebuilding parser.bc would then require only
> a single compiler call in src/backend/parser instead of many.
The other file also needs to be built. The .bc->.o dependency will actually
often prevent redundant error messages.
Greetings,
Andres Freund
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: .bc files build dependency issues.
In-Reply-To: <7ihq6kmoruqicq5qqns3wicb4yydrqgy4iqvke3wafa5f2h6i4@5y4pwfuogh2y>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox