@dbaio reported that "make makesum" was not working for lang/python-doc-html. This was something I had fixed last year via r492965.
r513191 does some cleanup of bsd.prog.mk:
Reduce code duplication by calling fetch target
when converting the do-fetch target to proper scripting we lost
the ability to overwrite do-fetch when running make makesum.
as reported here:
Let's call again do-fetch directly instead of duplicating its
This was a nice cleanup but broke makesum lang/python-doc-html and also some linux ports resulting in r514097:
Let "make makesum" pass DISTFILES to "make fetch". For Linux
ports "make makesum" downloads distfiles for all supported
architectures while "make fetch" only downloads files for the
This partially fixed lang/python-doc-html but MASTER_SITES also needs to be passed down to the sub-make; here's a patch to do that.
Created attachment 218195 [details]
It seems to me that the framework does not really need fixing, the port should be fixed instead.
Nothing prevents the port from having the correct MASTER_SITES value outside of make(makesum).
I don't think the fix is correct at all, you should absolutely never need to use .export.
I also needed to manually export MASTER_SITES for makesum. I don't
understand why the framework does not export MASTER_SITES to the
submake on its own. It exports DISTFILES for some reason since
ports 50d2c82e016fd176868cdc6e4befa606fa61c50e but not MASTER_SITES?
This looks like an oversight to me.
I know we could generate or set MASTER_SITES statically instead of
conditionally but that isn't exactly free. It would be pretty
awful to do this in lang/rust-bootstrap which currently has nested
conditional variables for each FLAVOR. It is already complicated
Is there any technical reason to not just commit this one line
patch? If not please approve it.
(In reply to Tobias Kortkamp from comment #5)
> It exports DISTFILES for some reason since ports 50d2c82e016fd176868cdc6e4befa606fa61c50e but not MASTER_SITES?
I believe it's the case that DISTFILES and MASTER_SITES are co-dependent and should receive the same treatment.
here is all context: ports r513191 and ports 50d2c82e016fd176868cdc6e4befa606fa61c50e
I can revert the export, but we will probably need to do that locally as well. Any other idea?