On Fri, Feb 10, 2017 at 10:39:48AM +0100, Sébastien Villemot wrote: > Le jeudi 09 février 2017 à 16:13 +0100, Michael Banck a écrit : > > > I think I read the ATLAS README.Debian and found it a bit more > > convoluted than necessary; in particular, I think it creates binary > > packages with different names to ones in the official archive (sorry > > can't check at the moment as I am on crappy dialup)? Probably just > > bumping the binary package version like we do for backports or binNMUs > > would be enough. > > Actually the package name remains the same as the official package, just > the version differs (a suffix is appended to the version number). > > > A good start would be to both support DEB_BUILD_OPTIONS=custom for > > generic performance-oriented rebuidls and > > DEB_CFLAGS_MAINT_APPEND=-march=native for for the -march=native thing. > > I’m not sure to understand what a “generic performance-oriented rebuild” > is. By definition, a performance-oriented rebuild does not create a > generic binary, but a target-specific one.
I meant generic as possibly doing other stuff[1] as opposed to "just" adding -march=native via DEB_CFLAGS_MAINT_APPEND. > However, I agree with you that using DEB_BUILD_OPTIONS rather than a > custom rule in debian/rules (as currently implemented) would be a nicer > technical solution. I’m going to open a bug against src:atlas to remind > myself to make that change for buster. OK, then maybe it was the custom debian/rules rule that rubbed me, and I misremembered it as custom package name, sorry. Thanks for opening a bug! Michael [1] Like doing trial-and-error with different code paths for different set sizes/cache line sizes I think ATLAS is doing; CP2K has the possiblity to auto-tune one of its internal libraries as well...
