Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1092817
| From | Nicolas Boulenguez <nicolas@debian.org> |
|---|---|
| Newsgroups | linux.debian.bugs.dist, linux.debian.maint.dpkg |
| Subject | Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules |
| Date | 2022-02-11 20:30 +0100 |
| Message-ID | <DPJMd-18Nl-13@gated-at.bofh.it> (permalink) |
| References | <ufgeu-58C-5@gated-at.bofh.it> <DPoHM-VMH-7@gated-at.bofh.it> <DPqgx-WOt-3@gated-at.bofh.it> <ufgeu-58C-5@gated-at.bofh.it> <DPqgx-WOt-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Cross-posted to 2 groups.
> > [in scripts/mk/Makefile.am], I suggest to rename
> > scripts/mk/{default,buildtools}.mk to scripts/mk/*.mk.sed or similar
> > (for example, .sed.mk in order to keep syntax highlighting). Distinct
> > source and object files would also simplify scripts/mk/Makefile a lot.
> Yeah, that would be more convenient, the problem is that these files
> need to have specific pathnames during tests, which are different from
> the ones at run-time. Those could be set from the environment, but that
> would miss the case where the variable is completely missing from the
> file. :)
Would this be OK?
dpkg_datadir := $(shell $(dir $(lastword $(MAKEFILE_LIST))))
If I remember well, only GNU Make supports this, but else something
like
dpkg_datadir != dirname `echo $(MAKEFILE_LIST) | sed 's/.* //'`
could probably be improved to compute the result only once.
> The main issue I see is that this trades performance depending on the
> mode of operation. Some of these variables are (currently) not
> expected to be set by the driver calling debian/rules (in Debian we
> still have to support that being any thing :/), but then most of our
> tools do go through dpkg-buildpackage. So the various «.mk» cannot
> expect these variables to be previously set, but should assume that
> the common case is them being executed through dpkg-buildpackage, and
> that one setting some of those, which means unconditionally setting
> some of them will make the package builds somewhat slower. The other
> variables should then not be set if not used, as that would slow down
> packages that do not need them.
As far as I have tested, my suggestion behaves exactly like the
current one. The only difference is that when several variables are
unset, the related dpkg-{architecture,buildflags,..} tool is called
only once.
> Ideally, most of this would not be needed at all, because we could
> rely on dpkg-buildpackage having exported all of these, which it
> already needs to compute in most cases anyway, but this is something
> we cannot have in Debian for now. I'm pondering adding a mode, not to
> be used by Debian, which could be used by local packages or other
> distros though.
A variable like DEB_BUILD_FLAGS_ALREADY_SET could shortcut all tests,
but I wonder if the speed gain would be worth the added complexity,
assuming that each dpkg-{architecture,buildflags,...} is called at
most once and only if at least a variable is both unset and actually
read.
> I'll go over these in the coming days.
I will do my best to rebase before that :-)
Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Find similar | Unroll thread
Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules Nicolas Boulenguez <nicolas@debian.org> - 2022-02-10 22:00 +0100
Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules Guillem Jover <guillem@debian.org> - 2022-02-10 23:40 +0100
Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules Nicolas Boulenguez <nicolas@debian.org> - 2022-02-11 20:30 +0100
csiph-web