Mark Millard wrote:
> > Perhaps you want to be using
> >
> > .MAKE.META.IGNORE_PATHS+= ${MAKEOBJDIRPREFIX}/tmp/legacy/usr
> > or is that ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr
> >
>
> I had started with trying to use MAKEOBJDIRPREFIX but it
> appeared to end up with an empty
On Feb 23, 2023, at 19:54, Simon J. Gerraty wrote:
>
>>
>> First some output log lines around a few sbin/realpath "is newer than"
>> related Building lines, with the .info lines in place now (I've
>> got both kmod.mk and kern.mk with the .info line, likely producing
>> redundant output but I did
>
> First some output log lines around a few sbin/realpath "is newer than"
> related Building lines, with the .info lines in place now (I've
> got both kmod.mk and kern.mk with the .info line, likely producing
> redundant output but I did not know up front for sure):
>
> make[4]: "/usr/main-src/s
[I'm back at this again after some time on other subjects.]
On Feb 23, 2023, at 17:42, Simon J. Gerraty wrote:
> Mark Millard wrote:
>
>> Simplifying context . . .
>> . . .
>>> As I mentioned previously, there is no variablity of OBJTOP within the
>>> context of a single make instance - at lea
Mark Millard wrote:
> Simplifying context . . .
> . . .
> > As I mentioned previously, there is no variablity of OBJTOP within the
> > context of a single make instance - at least not once it starts running
> > targets.
> >
> >> . . .
> >
> > .MAKE.META.IGNORE_PATHS += ${OBJTOP}/tmp/legacy/usr
>
On Feb 23, 2023, at 14:03, Simon J. Gerraty wrote:
Simplifying context . . .
. . .
> As I mentioned previously, there is no variablity of OBJTOP within the
> context of a single make instance - at least not once it starts running
> targets.
>
>> . . .
>
> .MAKE.META.IGNORE_PATHS += ${OBJTOP}/tm
Mark Millard wrote:
> [External Email. Be cautious of content]
>
>
> [Note for "how many separate bmake instances are in that log?":
> I do not know how to tell how many submakes are run total. It
> was with -j32 on the threadripper 1950X, if that is was you
> were after.]
You can get a clue f
Mark Millard wrote:
> So I was hoping for a "assigned once and
> inherited" status relative to submakes for
> .MAKE.META.IGNORE_PATHS .
No, .MAKE.* are specifically named to ensure they cannot come from the
environment. So bounding them in a check for level 0 pretty much
ensures they have no eff
[Note for "how many separate bmake instances are in that log?":
I do not know how to tell how many submakes are run total. It
was with -j32 on the threadripper 1950X, if that is was you
were after.]
On Feb 23, 2023, at 12:25, Simon J. Gerraty wrote:
> Mark Millard wrote:
. . .
>
>> I got
On Feb 23, 2023, at 12:15, Simon J. Gerraty wrote:
> Mark Millard wrote:
>> The contribution to the list is currently generated via
>> use of:
>>
>> .if ${.MAKE.LEVEL} == 0
>
> Why is this guarded by .MAKE.LEVEL 0?
> .MAKE.META.IGNORE_* should be largely irrelevant at level 0
> which in the DI
Mark Millard wrote:
> So with -ddM why do I see lots of "cached_realpath:"
> notices for the same path? For example:
how many separate bmake instances are in that log?
>
> # grep "tmp/legacy/usr/sbin/ln\>"
> /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd64-nodbg-cla
Mark Millard wrote:
> >> Also, OBJTOP is not constant over all the parts of
> >> buildworld buildkernel . Having the late-substitution
> >> form of notation ${OBJTOP} might not be appropriate
> >> for the content of .MAKE.META.IGNORE_PATHS .
> >
> > Fwiw .MAKE.META.IGNORE_PATHS is evaluated when m
On Feb 23, 2023, at 11:53, Mark Millard wrote:
> cached_realpath only reports its "cached_realpath:" notice
> (not the purging one) when it does not find the value via
> HashTable_FindValue and so does a HashTable_Set :
>
> const char *
> cached_realpath(const char *pathname, char *resolved)
> {
Mark Millard wrote:
> The contribution to the list is currently generated via
> use of:
>
> .if ${.MAKE.LEVEL} == 0
Why is this guarded by .MAKE.LEVEL 0?
.MAKE.META.IGNORE_* should be largely irrelevant at level 0
which in the DIRDEPS_BUILD is reserved for orchestration.
Even in the legacy build
cached_realpath only reports its "cached_realpath:" notice
(not the purging one) when it does not find the value via
HashTable_FindValue and so does a HashTable_Set :
const char *
cached_realpath(const char *pathname, char *resolved)
{
const char *rp;
if (pathname == NULL || pathn
Hello Mina,
thanks for the PR, I can confirm that this bugfix is working.
@Warner, could you commit it?
I think creating a differential for the small change isn't neccessary.
--Gordon
On Thu, Feb 23, 2023 at 10:05:25AM +, Mina Galić wrote:
> taking Simon off the list, cuz his auto - reply
taking Simon off the list, cuz his auto - reply indicates he's very busy.
Either way, t should do it: https://github.com/freebsd/freebsd-src/pull/657
Mina Galić
Try PkgBase: https://alpha.pkgbase.live/
Original Message
On 23 Feb 2023, 09:57, Mina Galić wrote:
> given that thi
given that this isn't contrib code, we can just fix it in our tree:
https://github.com/freebsd/freebsd-src/blob/main/sbin/veriexec/veriexec.c#L52
Mina Galić
Try PkgBase: https://alpha.pkgbase.live/
Original Message
On 23 Feb 2023, 09:27, Gordon Bergling wrote:
> Hi Simon, On
Hi Simon,
On Mon, Feb 20, 2023 at 09:23:48PM -0800, Simon J. Gerraty wrote:
> This has been fixed upstream, I'll look at importing an update.
Thanks for merging the upstream fix. BearSSL is now compiling, but I get a
different error now while building veriexec.
/boiler/nfs/src/sbin/veriexec/ve
On Feb 22, 2023, at 22:23, Simon J. Gerraty wrote:
> Mark Millard wrote:
>>>
>>> Is there anything under ${OBJTOP}/tmp that you don't want to ignore?
>>
>> More than just _bootstrap_tools_links entries end up in
>> ${WORLDTMP}/legacy/bin/ (so in ${WORLDTMP}/legacy/sbin/
>> via the symbolic li
20 matches
Mail list logo
