Colin Watson wrote: > Indeed, in general would it make sense to have dh_auto_configure > implement noopt itself rather than relying on dpkg-buildpackage to do > it? A lot of my packages have a bit in debian/rules that handles noopt, > and I'm sort of reluctant to remove that based solely on > dpkg-buildpackage's handling - having the debhelper buildsystems take > care of it would be lovely.
For some packages, -O0 may be known not to work and -O1 be used instead for noopt, per policy. I imagine such packages currently have a debian/rules that checks for noopt and sets CFLAGS appropriatly. So if dh_auto_configure implemented noopt itself, it would need to at least avoid clobbering any existing CFLAGS. But of course that means the dpkg-buildpackage CFLAGS would still be used in the common case. So the only reason would be to handle builds done w/o dpkg-buildpackage. However, the dpkg maintainers seemed to want to not support that, when they made the choice to make dpkg-buildpackage handle noopt. (I seem to remember a long thread about it.) Of course if a build system doesn't use CFLAGS directly, it's ok for dh_auto_configure to pass the CFLAGS setting through to it, assuming that the dpkg-buildpackage default won't break something. And if a build system doesn't support -O0 at all, but has some other way to build w/o optimisations, it would probably be ok for dh_auto_configure to handle noopt itself in that case, though I'd want there to be some way for the rules file to override whatever mechanism is used. Now, back to the specific case of perl packages. In MakeMaker, OPTIMIZE apparently defaults to -O (according to its docs, but I have not found it in the code..). Will changing that default to dpkg-buildpackage's default of -O2 break anything? How can we tell? (How were the dpkg maintainer's able to tell when they started setting CFLAGS for everything?) I haven't been able to figure out how build=optimize=-02 works in Module::Build, or what the default is. -- see shy jo
signature.asc
Description: Digital signature
