Hi Nico,
Ok, should we add some of the extra Debian flags you brought up to our
Scons script?
Unfortunately we have actually a hardware limitation.
We need a CPU that allows hardware denormals prevention.
This is true for Intel >= Pentium 4 and all ARM CPUs
Fixing this with a software solution is possible, but not worth the work
for such old CPUs.
If this is not fixed user will face underflows when stopping a deck and
using EQs.
https://github.com/mixxxdj/mixxx/pull/438
So we should ensure, that the Debian builds uses the
the following option after merging the optimize_gcc branch.
optimize=portable
2015-02-03 10:36 GMT+01:00 Nico Schlömer <nico.schloe...@gmail.com>:
> So it seems that I was wrong and in Debian we are actually allowed to
> use our own flags, cf. the thread starting at [1]. The only
> limitation: Don't use flags that make assumptions about the platform.
>
> –Nico
>
>
> [1] https://lists.debian.org/debian-mentors/2015/02/msg00025.html
>
> On Tue, Feb 3, 2015 at 12:53 AM, Nico Schlömer <nico.schloe...@gmail.com>
> wrote:
> >> Remember that we already rebuild some libraries to have an
> >> optimized build.
> >
> > I must say that in this particular instance I see the benefit of
> > compiling a Mixxx-dependency with `-O3`. Then again, many packages
> > would profit from `-O3` in a similar way. Allowing all packages to
> > handle their own dependencies and build flags would probably lead to a
> > fair amount of chaos in the distribution. This is the reason why most
> > Debian devs have a strong opinion *against* custom dependency and
> > build flags handling, and sure enough, the in-mixxx building of
> > dependencies is patched out in Debian to use the system libs instead
> > [1]
> >
> > I'm not aware of any package that handles its own build flags, but
> > I'll ask on the mailing list what people's options are.
> >
> > Oh, and of course a big thanks for implementing the `none` build type!
> >
> > Cheers,
> > Nico
> >
> >
> >
> > [1]
> http://metadata.ftp-master.debian.org/changelogs/main/m/mixxx/unstable_changelog
> ,
> > changes for 1.9.0+dfsg0-1
> >
> >
> >
> >
> > On Mon, Feb 2, 2015 at 11:27 PM, Daniel Schürmann <dasch...@mixxx.org>
> wrote:
> >> Hi Nico,
> >>
> >> our equivalent to CMAKE_BUILD_TYPE is
> >> build=debug
> >> and
> >> build=release
> >>
> >> both adds
> >> -pipe -Wall -Wextra -g
> >>
> >> CMake supports these builds by default:
> >> None Debug Release RelWithDebInfo and MinSizeRel
> >>
> >> We may add a build=none option to use no compiler flags.
> >>
> >> But I am still in the opinion that we should not rely on tools like
> >> dpkg-buildflags to set build flags for most debian based distributions.
> >> Remember that we already rebuild some libraries to have an
> >> optimized build. This would have no effect with a build=none option.
> >>
> >> Do you have actually an issue with applying both, the Debian flags
> >> an our portable flags?
> >> If you have one, I would prefer to fix this in the fist place.
> >>
> >>
> >> Am 02.02.2015 um 20:25 schrieb Nico Schlömer:
> >>
> >>>> how does Debian set these flags.
> >>>
> >>> Via the environment variables (CFLAGS & friends). They are then picked
> >>> up by the build system, e.g., SCons.
> >>>
> >>>> What is the issue with [...]
> >>>
> >>> There's nothing wrong with any of these options as long as there is
> >>> there is a way to turn them off. If you're building production code
> >>> for a machine, you might not want `-Wall` or `-g` because you're not
> >>> debugging, but shipping. Or maybe you want to optimize for binary
> >>> size, then you go for `-Os` and not `-O3`. Ultimately, the choice of
> >>> compiler and compile options is best left to the person who actually
> >>> compiles the code, and it shouldn't be hardcoded in the build system.
> >>> That said, some sane common defaults can be provided (with the
> >>> possibility to turn them off).
> >>>
> >>>> But that is not what we want the user to use ob Debian systems
> >>>
> >>> There is a difference between a user of a Debian system who builds
> >>> Mixxx in his $HOME, and the actual Debian package. For the former, I
> >>> concur that it's perfectly okay to default to `optimize=portable` or
> >>> whatever you deem best for the average user.
> >>>
> >>>> optimize=disable
> >>>
> >>> Unfortunately, "optimize" isn't very explanatory. Does this concern
> >>> only the "-Ox" flag? What I would vote for is a build option that
> >>> allows me to remove *all* custom compiler flags (just like CMake's
> >>> CMAKE_BUILD_TYPE=None).
> >>>
> >>> Cheers,
> >>> Nico
> >>>
> >>>
> >>> On Mon, Feb 2, 2015 at 3:56 PM, Daniel Schürmann <dasch...@mixxx.org>
> >>> wrote:
> >>>>
> >>>> Hi Nico,
> >>>>
> >>>> how does Debian set these flags. Is there a building script with some
> >>>> arguments, resulting in in this options?
> >>>> This commit switches from CXX to CC flags
> >>>>
> >>>>
> https://github.com/daschuer/mixxx/commit/7d3fe7d9df55d5805e514f82b6968e168903936a
> >>>> So it should work.
> >>>>
> >>>> After merging https://github.com/mixxxdj/mixxx/pull/436
> >>>> We will have the option, which should include no optimization compiler
> >>>> flags:
> >>>>
> >>>> optimize=disable
> >>>>
> >>>> But that is not what we want the user to use ob Debian systems even if
> >>>> "-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> >>>> -Werror=format-security -D_FORTIFY_SOURCE=2" is added.
> >>>>
> >>>> The user should use a
> >>>>
> >>>> optimize=portable
> >>>>
> >>>> build.
> >>>>
> >>>> We may add an additional option to optimize for Debian builds.
> >>>>
> >>>> What is the issue with -Wall -Wextra? I hope we can finally eliminate
> all
> >>>> warnings an build with -Werror.
> >>>>
> >>>> What is the issue with -O3 and -funroll-loops?
> >>>>
> >>>> I have checked the engine execution time and "-O3 -ffast-math
> >>>> -funroll-loops
> >>>> -fomit-frame-pointer" has proven to produce the fastest results.
> >>>>
> >>>> -fomit-frame-pointer is not default for optimized builds in any case:
> >>>> "-O also turns on -fomit-frame-pointer on machines where doing so does
> >>>> not
> >>>> interfere with debugging."
> >>>> see also:
> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16373
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 2015-02-02 12:28 GMT+01:00 Nico Schlömer <nico.schloe...@gmail.com>:
> >>>>>
> >>>>> Debian sets
> >>>>> ```
> >>>>> -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> >>>>> -Werror=format-security -D_FORTIFY_SOURCE=2
> >>>>> ```
> >>>>> and Mixxx nonchalantly adds
> >>>>> ```
> >>>>> -pipe -Wall -Wextra -g -pthread -O3 -ffast-math -funroll-loops
> >>>>> -fomit-frame-pointer
> >>>>> ```
> >>>>> It'd be arguably cleaner if Mixxx had a option that does *not* add
> any
> >>>>> flags, for example for someone who is not interested in `-Wall
> >>>>> -Wextra` or `-O3` (the former really doesn't seem like something
> you'd
> >>>>> want to ship for production builds). CMake, for example, typically
> >>>>> handles this via `CMAKE_BUILD_TYPE=None`.
> >>>>> Also, the effect of `-funroll` loops is debatable and should possibly
> >>>>> not be enabled by default.
> >>>>> As a side note, `-fomit-frame-pointer` is
> >>>>> ```
> >>>>> Enabled at levels -O, -O2, -O3, -Os.
> >>>>> ```
> >>>>> so we can get rid of this entirely.
> >>>>>
> >>>>> Cheers,
> >>>>> Nico
> >>>>>
> >>>>> On Sun, Feb 1, 2015 at 9:52 PM, Daniel Schürmann <dasch...@mixxx.org
> >
> >>>>> wrote:
> >>>>>>
> >>>>>> IMHO there is currently no way to bypass the Scons build flags.
> >>>>>> We may introduce such a way, but what is the use case to provide
> >>>>>> build flags from a Linux distributor?
> >>>>>>
> >>>>>> Even in a autotools project, they are set inside the build scrips
> >>>>>> maintained by the project.
> >>>>>> However I be aware that there is a complete tool-chain to automate
> >>>>>> various task in the build process.
> >>>>>>
> >>>>>> Which flags are set by Debian we have to be aware of?
> >>>>>>
> >>>>>>
> >>>>>> Am 01.02.2015 um 20:31 schrieb Nico Schlömer:
> >>>>>>
> >>>>>>>> Do you have special requirements.
> >>>>>>>
> >>>>>>> Well, I don't want SCons to interfere with the build flags I
> (/Debian)
> >>>>>>> provide.
> >>>>>>>
> >>>>>>> What are the SCons flags I'll have to set?
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Nico
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sun, Feb 1, 2015 at 9:06 PM, Daniel Schürmann <
> dasch...@mixxx.org>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi Nico,
> >>>>>>>>
> >>>>>>>> the build flags are generated from the various scons flags
> controlled
> >>>>>>>> by
> >>>>>>>> build/features.py and build/depends.py
> >>>>>>>> Please note that there is a pending pull request, that cleans up
> the
> >>>>>>>> flags a bit.
> >>>>>>>> https://github.com/mixxxdj/mixxx/pull/436
> >>>>>>>>
> >>>>>>>> Do you have special requirements.
> >>>>>>>>
> >>>>>>>> Kind regards,
> >>>>>>>>
> >>>>>>>> Daniel
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Am 01.02.2015 um 19:33 schrieb Nico Schlömer:
> >>>>>>>>>
> >>>>>>>>> Hi all,
> >>>>>>>>>
> >>>>>>>>> How can I build Mixxx with build flags entirely determined by the
> >>>>>>>>> environment? Currently, I'm getting
> >>>>>>>>> ```
> >>>>>>>>> [...]
> >>>>>>>>> Building with CC: gcc
> >>>>>>>>> Building with CXX: g++
> >>>>>>>>> Building with CCFLAGS: -pipe -Wall -Wextra -g -pthread -O3
> >>>>>>>>> -ffast-math
> >>>>>>>>> -funroll-loops -fomit-frame-pointer
> >>>>>>>>> Building with CPPDEFINES: -Damd64 -DMIXXX_BUILD_DEBUG -D__LINUX__
> >>>>>>>>> -D__UNIX__ -DSETTINGS_PATH=\".mixxx/\"
> -DSETTINGS_FILE=\"mixxx.cfg\"
> >>>>>>>>> -DUNIX_SHARE_PATH=\"/usr/share/mixxx\"
> >>>>>>>>> -DUNIX_LIB_PATH=\"/usr/lib/mixxx\" -D__PORTAUDIO__ -DQT_SHARED
> >>>>>>>>> -DQT_TABLET_SUPPORT -DQT_CORE_LIB -DQT_GUI_LIB -DQT_OPENGL_LIB
> >>>>>>>>> -DQT_XML_LIB -DQT_SVG_LIB -DQT_SQL_LIB -DQT_SCRIPT_LIB
> >>>>>>>>> -DQT_NETWORK_LIB -DQT_SHARED -D__SNDFILE__ -D__MAD__ -D__HID__
> >>>>>>>>> -D__BULK__ -D__VINYLCONTROL__ -D__SHOUTCAST__ -DHAVE_FFTW3
> >>>>>>>>> -D__AUTODJCRATES__ -D__SQLITE3__
> >>>>>>>>> Building with CXXFLAGS: -g -O2 -fstack-protector
> >>>>>>>>> --param=ssp-buffer-size=4 -Wformat -Werror=format-security
> >>>>>>>>> -D_FORTIFY_SOURCE=2
> >>>>>>>>> ```
> >>>>>>>>> where the CXXFLAGS are from the environment and the CCFLAGS
> from...
> >>>>>>>>> Well, I have no idea where from actually.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Nico
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> ------------------------------------------------------------------------------
> >>>>>>>>> Dive into the World of Parallel Programming. The Go Parallel
> >>>>>>>>> Website,
> >>>>>>>>> sponsored by Intel and developed in partnership with Slashdot
> Media,
> >>>>>>>>> is
> >>>>>>>>> your
> >>>>>>>>> hub for all things parallel software development, from weekly
> >>>>>>>>> thought
> >>>>>>>>> leadership blogs to news, videos, case studies, tutorials and
> more.
> >>>>>>>>> Take
> >>>>>>>>> a
> >>>>>>>>> look and join the conversation now.
> >>>>>>>>> http://goparallel.sourceforge.net/
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> >>>>>>>>> http://mixxx.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Mixxx-devel mailing list
> >>>>>>>>> Mixxx-devel@lists.sourceforge.net
> >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ------------------------------------------------------------------------------
> >>>>>>>> Dive into the World of Parallel Programming. The Go Parallel
> Website,
> >>>>>>>> sponsored by Intel and developed in partnership with Slashdot
> Media,
> >>>>>>>> is
> >>>>>>>> your
> >>>>>>>> hub for all things parallel software development, from weekly
> thought
> >>>>>>>> leadership blogs to news, videos, case studies, tutorials and
> more.
> >>>>>>>> Take
> >>>>>>>> a
> >>>>>>>> look and join the conversation now.
> >>>>>>>> http://goparallel.sourceforge.net/
> >>>>>>>> _______________________________________________
> >>>>>>>> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> >>>>>>>> http://mixxx.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Mixxx-devel mailing list
> >>>>>>>> Mixxx-devel@lists.sourceforge.net
> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
> >>>>>>
> >>>>>>
> >>>>
> >>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
