similar to: Github action build for CMake and AutoMake

Hi, I would like to start using GitHub Actions[1] for CI testing on the release/* branches. As far as I know we don't have any buildbots listening to the release branches, and I think GitHub Actions are a good way for us to quickly bring-up some CI jobs there. My proposal is to start by adding two post-commit CI jobs to the release/9.x branch. One for building and testing (ninja checka-all)

Did the patch 5 split / AVX fix work get merged at all, I didn't see any more mails about it? Thanks! On Tue, 14 Jan 2020 at 21:34, Marcus Asteborg <xnorpx at outlook.com> wrote: > Awesome thanks! Good comments. > > Please apply patch 1-4 and I prepare another iteration on patch 5 for you > too look at. > > //Marcus > ------------------------------ > *From:*

Hi Simon, Please create a pull request here: https://github.com/xnorpx/opus/pulls Also please add a buildconfig here that exercise the BUILD_FRAMEWORK option: https://github.com/xnorpx/opus/blob/master/.github/workflows/build.yml [https://avatars2.githubusercontent.com/u/302709?s=400&v=4]<https://github.com/xnorpx/opus/blob/master/.github/workflows/build.yml>

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

Verified that intrin0.h was available in 1910, by building it locally on VS2017 version 15.0 MSVC++ 14.1 _MSC_VER == 1910 (Visual Studio 2017 version 15.0) https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B //Marcus ________________________________ From: Marcus Asteborg <xnorpx at outlook.com> Sent: Thursday, June 11, 2020 20:15 To: Ralph Giles <giles at thaumas.net>; opus at

>>> Marcus Asteborg <xnorpx at outlook.com> schrieb am 24.06.2020 um 19:59 in Nachricht <8175_1593021574_5EF39486_8175_1287_1_DB3PR0602MB378816E9B5FC531496C4CE9FDF950 at D 3PR0602MB3788.eurprd06.prod.outlook.com>: > > ________________________________ > From: Mark Harris <mark.hsj at gmail.com> > Sent: Wednesday, June 24, 2020 00:09 > To: Marcus Asteborg

3, no good catch attached is an updated patch //Marcus ________________________________ From: Jean-Marc Valin <jmvalin at jmvalin.ca> Sent: Thursday, June 11, 2020 10:49 To: Marcus Asteborg <xnorpx at outlook.com>; opus at xiph.org <opus at xiph.org> Subject: Re: [opus] Misc patches On 2020-06-08 01:39, Marcus Asteborg wrote: > 1. Build test for cmake and run the test in

Sorry about that, let me check the correct version for the intrin0.h include guard. //Marcus ________________________________ From: Ralph Giles <giles at thaumas.net> Sent: Thursday, June 11, 2020 19:31 To: Marcus Asteborg <xnorpx at outlook.com>; opus at xiph.org <opus at xiph.org> Subject: Re: [opus] Misc patches Speaking of needing more complete ci feedback, the intrin0.h

Hi, Here is a proposal for adding CMake in addition of Autotools. See attached patch for changes or the pull request here: https://github.com/xiph/opus/pull/100 The CMake scripts are parsing the filelist from Autotools, so only one file list needs to be maintained. With this change the checked in Visual Studio solution can be removed and no longer need to be maintained and updated when

On Sat, Jun 13, 2020 at 2:59 PM Marcus Asteborg <xnorpx at outlook.com> wrote: > > Hi, > > Here is a patch to add build instructions for CMake to the README. > > I tried to follow the previous automake style instructions as closely as possible but added instructions for Windows. > Noted that it is still experimental > > //Marcus Hi Marcus, Currently the build

________________________________ From: Mark Harris <mark.hsj at gmail.com> Sent: Wednesday, June 24, 2020 00:09 To: Marcus Asteborg <xnorpx at outlook.com> Cc: opus at xiph.org <opus at xiph.org> Subject: Re: Add CMake build instructions to README > Hi Marcus, > Currently the build instructions start with simple instructions for > building from the release tarball, and

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

Hi Marcus, When building shared libraries for macOS / iOS /tvOS, by default `.dylib` shared libraries will be generated. With this patch `BUILD_FRAMEWORK` is exposed as an option allowing the user to specify that a `.framework` bundle should be built instead of a standalone `.dylib` file. Enabling the option sets the necessary target properties to instruct CMake to do this. The Ogg CMake build

Signed-off-by: Doug Goldstein <cardoe at gentoo.org> --- Makefile.am | 2 +- configure.ac | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: fee51bc27d60c7ec9d0371af88a476a232d9a8bd.diff Type: text/x-patch Size: 761 bytes Desc: not available Url :

From: "Richard W.M. Jones" <rjones at redhat.com> Earlier versions of automake complain if they get a configuration parameter which they don't understand. The error is: configure.ac:27: error: option 'serial-tests' not recognized Use some m4 hackery to work around this. --- configure.ac | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff

Could someone please check and see what I am doing wrong with automake in branches/AsciiDoc? http://boxster.ghz.cc/projects/nut/browser/branches/AsciiDoc/docs/Makefile.am?rev=1917 The problem is that 'make html' never recurses into docs/website. I have listed 'website' in the 'SUBDIRS' section of docs/Makefile.am, and 'docs/website/Makefile' is listed in the

http://bugzilla.netfilter.org/show_bug.cgi?id=798 Summary: fix warning with newer automake Product: iptables Version: unspecified Platform: x86_64 OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: iptables AssignedTo: netfilter-buglog at lists.netfilter.org

--- perl/Makefile.am | 4 ++-- resize/Makefile.am | 8 +++++--- sparsify/Makefile.am | 8 +++++--- 3 files changed, 12 insertions(+), 8 deletions(-) diff --git a/perl/Makefile.am b/perl/Makefile.am index eff0059..5e29bbd 100644 --- a/perl/Makefile.am +++ b/perl/Makefile.am @@ -40,11 +40,9 @@ if HAVE_PERL # a nightmare, news at 11. # src/ dependencies -.PHONY: src_deps

Hi Rich, I realized a day or two late that my suggestion was not quite right. Here's the fix: >From 5294c21cf07c4ec2f094182ba9f32696f3de2751 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Mon, 23 Jan 2012 10:01:40 +0100 Subject: [PATCH libguestfs] build: don't use automake-internal variable * ocaml/Makefile.am (mlguestfs.cma): Use the documented

If you rebuild the Makefiles using automake >= 1.13 then you'll likely hit this error: Makefile:1904: *** unterminated variable reference. Stop. This is caused by automake miscompiling GNU make macros that appear in the 'TESTS' variable decl in 'ocaml/Makefile.am'. I posted a bug about this upstream. It hasn't appeared yet, but it should turn up here in the near