thr3ads.net - opus - [opus] Opus cmake build [Apr 2019]

If this information is useful, please help other people find it:
Share via:

Cristian Adam

2019-Apr-11 07:30 UTC

[opus] Opus cmake build

On Wed, Apr 10, 2019 at 5:30 PM Marcus Asteborg <xnorpx at outlook.com>
wrote:
> Hi Mark,
>
> Thanks for the feedback.
>
> By default CMake is building the static library in debug, to get other
> things one has to explicit turn it on.
>
>Hi,

By default CMake uses the "empty" build, which is used in combination
with
the environment variables CFLAGS and CXXFLAGS.

This build type is targeted at Linux distributions which want to use the
same compiler flags for multiple packages.

If you want to change the default build type to something else when
CMAKE_BUILD_TYPE is empty, make sure that you do that when $ENV{CFLAGS} and
$ENV{CXXFLAGS} are not set.

There is a blog entry at Kitware
https://blog.kitware.com/cmake-and-the-default-build-type/ on this topic.
Unfortunately it doesn't address the  CFLAGS, CXXFLAGS issue. I guess one
can combine the both and have an optimal solution.

Cheers,
Cristian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/opus/attachments/20190411/5f447fce/attachment.html>

Marcus Asteborg

2019-Apr-11 17:17 UTC

head link

[opus] Opus cmake build

Hi Christian Adam,

Thanks for pointing this out, I made the necessary changes to account for this.

So the behavior is as follows:

  *
If no CMAKE_BUILD_TYPE is set and no CFLAGS are set it will default to Release.
i.e ( cmake .. )
  *
If a developer want full control then use export CFLAGS in leave
CMAKE_BUILD_TYPE empty.
  *
If a developer want to test CFLAGS in combination with CMAKE_BUILD_TYPE one has
to specify CMAKE_BUILD_TYPE and export the CFLAGS

https://github.com/xiph/opus/pull/118
[https://avatars0.githubusercontent.com/u/8365509?s=400&v=4]<https://github.com/xiph/opus/pull/118>

CMake - If CMAKE_BUILD_TYPE is empty and CFlags are set then only use… by xnorpx
· Pull Request #118 · xiph/opus<https://github.com/xiph/opus/pull/118>
CMake - If CMAKE_BUILD_TYPE is empty and CFlags are set then only use CFlags. If
None are set then use CMAKE_BUILD_TYPE by Release by default.
github.com

//Marcus

________________________________
From: Cristian Adam <cristian.adam at gmail.com>
Sent: Thursday, April 11, 2019 00:30
To: Marcus Asteborg
Cc: Mark Harris; opus at xiph.org
Subject: Re: [opus] Opus cmake build

On Wed, Apr 10, 2019 at 5:30 PM Marcus Asteborg <xnorpx at
outlook.com<mailto:xnorpx at outlook.com>> wrote:
Hi Mark,

Thanks for the feedback.

By default CMake is building the static library in debug, to get other things
one has to explicit turn it on.


Hi,

By default CMake uses the "empty" build, which is used in combination
with the environment variables CFLAGS and CXXFLAGS.

This build type is targeted at Linux distributions which want to use the same
compiler flags for multiple packages.

If you want to change the default build type to something else when
CMAKE_BUILD_TYPE is empty, make sure that you do that when $ENV{CFLAGS} and
$ENV{CXXFLAGS} are not set.

There is a blog entry at Kitware
https://blog.kitware.com/cmake-and-the-default-build-type/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.kitware.com%2Fcmake-and-the-default-build-type%2F&data=02%7C01%7C%7C0fdff823fe65421696db08d6be4f8a76%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636905646161553123&sdata=dcGdrZYlPvnZ1x9Rgvj8%2BxbKkEn1HP9xOCnoMYlqIco%3D&reserved=0>
on this topic. Unfortunately it doesn't address the  CFLAGS, CXXFLAGS issue.
I guess one can combine the both and have an optimal solution.

Cheers,
Cristian.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/opus/attachments/20190411/4fd16178/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-CMake-If-CMAKE_BUILD_TYPE-is-empty-and-CFlags-are-se.patch
Type: application/octet-stream
Size: 2612 bytes
Desc: 0001-CMake-If-CMAKE_BUILD_TYPE-is-empty-and-CFlags-are-se.patch
URL:
<http://lists.xiph.org/pipermail/opus/attachments/20190411/4fd16178/attachment.obj>

Mark Harris

2019-Apr-14 05:12 UTC

head link

[opus] Opus cmake build

Hi Marcus,

Thanks for the fixes.  I did some more cmake build testing and
encountered a few issues:

The option -DFORTIFY_SOURCE=2 should be -D_FORTIFY_SOURCE=2, as the
macro has a leading underscore.  In the autotools build it defines this
if it is not already defined (m4/ax_add_fortify_source.m4).

When custom modes are not enabled, the cmake build is nevertheless
installing the include file opus_custom.h.  This file is specific to
custom modes and should only be installed if custom modes were enabled.

It appears that the documentation is not being built or installed by the
cmake build; the autotools build builds and installs the documentation
by default unless configured with --disable-doc.

The option -DBUILD_SHARED_LIBS=ON causes a shared library to be built,
however it then does not build a static library.  The autotools build
builds both by default, although --disable-shared or --disable-static
may be used to disable them.  Normally an installation would have both.
 How can both be built with cmake?  Is it it necessary to build twice?

When configured with -DBUILD_TESTING=ON, ctest runs only 2 tests if
-DBUILD_SHARED_LIBS=ON was also used, or 4 tests without that option.
How would someone run all 14 of the tests that are run using the
autotools "make check"?  I wouldn't expect fewer tests to be run
when
shared libraries are built; the autotools build runs all tests
regardless of whether a shared library, static library, or both are built.
>  For programs use:
> -DBUILD_PROGRAMS=ON
I tried the option -DBUILD_PROGRAMS=ON that you mentioned, but it still
said that BUILD_PROGRAMS was disabled:

  -- The following features have been disabled:

   * USE_ALLOCA, Use alloca for stack arrays (on non-C99 compilers)
   * CUSTOM_MODES, Enable non-Opus modes, e.g. 44.1 kHz & 2^n frames
   * BUILD_PROGRAMS, Build programs
   * FIXED_POINT, compile as fixed-point (for machines without a fast
enough FPU)
   * X86_PRESUME_SSE4_1, assume target CPU has SSE4_1 support
   * X86_PRESUME_AVX, assume target CPU has AVX support

  -- Configuring done
  -- Generating done
  CMake Warning:
    Manually-specified variables were not used by the project:

      BUILD_PROGRAMS

By looking through CMakeLists.txt I figured out that I need to specify
-DOPUS_BUILD_PROGRAMS=ON.  Is it possible to make BUILD_TESTING and
BUILD_PROGRAMS consistent?  Also the output of cmake is misleading, as
it says BUILD_PROGRAMS not OPUS_BUILD_PROGRAMS.  For some settings it is
even worse; for example it says FLOAT_API but the actual -D option that
needs to be used to change that setting is -DOPUS_ENABLE_FLOAT_API=OFF.
 Can these be made consistent as well?

There also seems to be several configure options (see ./configure
--help) that have no equivalent, including --enable-assertions,
--disable-asm, --disable-intrinsics, --with-NE10, and rare options like
--disable-rfc8251, --disable-hardening, --enable-fixed-point-debug,
--enable-float-approx, --enable-fuzzing, and --enable-check-asm.

I tried a cmake build on a non-x86 Linux host but encountered numerous
warnings of the form:
  celt/float_cast.h:129:10: warning: #warning "Don't have the functions
lrint() and lrintf ()." [-Wcpp]
  celt/float_cast.h:130:10: warning: #warning "Replacing these functions
with a standard C cast." [-Wcpp]

The host does have both the lrint and lrintf functions; the problem is
that cmake did not define either HAVE_LRINT or HAVE_LRINTF.

 - Mark

Possibly Parallel Threads

Search for more maybe matching threads

opus - Apr 2019 - Opus cmake build

[opus] Opus cmake build

[opus] Opus cmake build

[opus] Opus cmake build

Possibly Parallel Threads