Hi,
Please bear with this question concerning an install that doesn't use the
latest build of everything...
I see that the gobject_introspection PG has support for disabling the feature
when the meson build system is used, supposes the option is provided
universally and needs to be acti
nothing to do with meson or older compilers or @rpaths in general.
the otool in cctools 949 does not call llvm-objdump-11+ (including -devel)
with full args it likes. (llvm-11+ changed their supported args. )
That is why cctools defaults to llvm-10.
don't use cctools +llvmdev unless y
/meson
--internal symbolextractor
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_multimedia_dav1d/dav1d/work/build
src/libdav1d.5.dylib src/libdav1d.5.dylib
src/libdav1d.5.dylib.p/libdav1d.5.dylib.symbols
:info:build WARNING: ['nm'] does not work. Relinking w
> On Feb 9, 2021, at 12:04 AM, Ken Cunningham
> wrote:
>
>
> PS — any feedback on the success of the cross building, or any failures
> encountered, would be much appreciated. I believe this is the only setup
> that currently allows meson cross building on BigSur
as meson was currently broken on older systems I pushed through a fix for this
just now.
We can revise it to whatever upstream wants to do when they get around to it,
if they want to do anything about it.
I took the opportunity to also add a cross file similar to the ones I added
previously
> On Feb 6, 2021, at 4:47 AM, Ryan Schmidt wrote:
>
>
>
> On Feb 6, 2021, at 02:14, Ken Cunningham wrote:
>
>> On Feb 5, 2021, at 10:04 PM, Ryan Schmidt wrote:
>>
>>> That sounds like what Craig is saying: that meson is now adding a compiler
>&
On Feb 6, 2021, at 02:14, Ken Cunningham wrote:
> On Feb 5, 2021, at 10:04 PM, Ryan Schmidt wrote:
>
>> That sounds like what Craig is saying: that meson is now adding a compiler
>> flag that old compilers don't understand. Meson should check whether a
>> compi
> On Feb 5, 2021, at 10:04 PM, Ryan Schmidt wrote:
>
> That sounds like what Craig is saying: that meson is now adding a compiler
> flag that old compilers don't understand. Meson should check whether a
> compiler supports a flag before it adds it. We should not be respo
On Feb 4, 2021, at 11:26, Ken Cunningham wrote:
> wait, I could have missed the issue...if meson is now adding a default
> argument to all checks that means it can never build anything with the
> default compilers on <10.10, that would be something we should consider
> fixing
wait, I could have missed the issue...if meson is now adding a default argument
to all checks that means it can never build anything with the default compilers
on <10.10, that would be something we should consider fixing in meson, even if
upstream doesn't want to.
So if testing shows
successful build with current meson on 10.6
https://build.macports.org/builders/ports-10.6_x86_64-builder/builds/47455/steps/install-port/logs/stdio
On Feb 4, 2021, at 08:48, Craig Treleaven wrote:
>> On Feb 3, 2021, at 10:01 PM, Joshua Root wrote:
>>
>> On 2021-2-4 12:1
well don't forget it builds just fine with the current meson on 10.6 using
clang-9.0.
so...nothing to do with meson, I would say.
Really, let's just blacklist older clangs and move alonglife is short.
Ken
On Feb 4, 2021, at 08:48, Craig Treleaven wrote:
>> On Feb 3, 2
t! I was really learning some things there. Perhaps
>> it can be tweaked still.
>> If not, I guess we can still use the compiler_blacklist_versions approach
>> and blacklist all the clangs < whatever 10.10 comes with.
>
> Well now I'm just confused, because the
compiler_blacklist_versions approach and
blacklist all the clangs < whatever 10.10 comes with.
Well now I'm just confused, because the test program builds fine on 10.7
outside of meson. Need to see the meson-log.txt.
- Josh
> On Feb 3, 2021, at 11:49 AM, Craig Treleaven wrote:
>
> But configure still failed on 10.7 and 10.8:
Oh no! It looked so great! I was really learning some things there. Perhaps it
can be tweaked still.
If not, I guess we can still use the compiler_blacklist_versions approach and
blacklis
on 10.6 with clang 9.0, so probably needs to blacklist clangs
>> older than 10.9's clang.
>> nothing to do with meson, looks to me...
>
> It's claimed to be written in C99, but requires either C11's stdatomic.h or
> GCC extensions. Hmmm.
>
> - Josh
On 2021-2-3 23:49 , Ken Cunningham wrote:
dav1d is failing on 10.7 and 10.8 on the configure test for atomic.
it's building on 10.6 with clang 9.0, so probably needs to blacklist clangs
older than 10.9's clang.
nothing to do with meson, looks to me...
It's claimed to be writ
sorry, another look, 10.9 fails so blacklist clangs older that 10.10's clang
should do it.
dav1d is failing on 10.7 and 10.8 on the configure test for atomic.
it's building on 10.6 with clang 9.0, so probably needs to blacklist clangs
older than 10.9's clang.
nothing to do with meson, looks to me...
K
It's a rare port that actually passes all the tests.
Best to compare with a current system and the previous meson before you
conclude anything is wrong for certain.
I've been running around enabling test suites on everything I can, including
meson
<https://github.com/macports/m
> On Feb 2, 2021, at 7:26 PM, Craig Treleaven wrote:
>
> Anyway, I have 'port test meson' running on my 10.10 system even though I
> don’t expect anything. I don’t have a working virtualization system at the
> moment. Perhaps tomorrow I can get that back up and try
On Feb 2, 2021, at 18:27, Craig Treleaven wrote:
> In the dav1d PR, CI didn’t produce results for the older OS versions. I
> thought the CI system was just being grumpy.
Our CI system uses publicly available build infrastructure from GitHub, which
only offers build machines running current
Ken:
I wasn’t trying to suggest that anybody failed at anything. The problem may be
specific to dav1d...but if it was more general, I wanted to alert others.
That’s all; I meant no offence to anyone.
And I could see how this might escape notice since it only affects meson on
older OS
I will try it.
If I might say — I would expect that anyone submitting a PR has at least built
the software on their local system, and used it enough to be sure it at least
basically works, if not ran the whole test suite.
SO — meson must have worked properly on at least the system that was
Hi:
It might be that the meson update and/or the switch to python39 has broken
builds on older Mac OS versions. Specifically, I updated dav1d to 0.8.1 and it
no longer configures successfully on 10.9 and older versions. Upstream says
that the now-failing configure test (a simple test to see
at what's going on on ppc.
> Another issue is that it's nontrivial to make tests work before binaries are
> installed.
I guess there won't be tests then. Hope this issue has been reported to the
meson devs...
> On Dec 30, 2017, at 11:52 PM, Ryan Schmidt wrote:
>
>> +# Meson's install_name currently seems to be broken, so workarounds might
>> be needed to make ports actually work.
>> +# See: https://github.com/mesonbuild/meson/issues/2121
>
> Yeah something is
31. dec. 2017 8:52 AM "Ryan Schmidt" wrote:
> +# Meson's install_name currently seems to be broken, so workarounds
might be needed to make ports actually work.
> +# See: https://github.com/mesonbuild/meson/issues/2121
Yeah something is going to have to get fixed there. I
317650a43d94f0026dade
>
> Author: Mojca Miklavec
> AuthorDate: Thu Nov 9 10:00:48 2017 +0100
>
>
> meson-1.0: new PortGroup
>
>
>
> The PortGroup supports building with the meson build system
>
> * http://mesonbuild.co
On 24 December 2017 at 21:02, Ryan Schmidt wrote:
> On Dec 22, 2017, at 18:10, Benjamin Redelings wrote:
>
>> However, even after that fix I have to define BOOST_ROOT=/opt/local to find
>> boost. For manual builds, if don't do PATH=/opt/local:$PATH then meson uses
>>
On Dec 22, 2017, at 18:10, Benjamin Redelings wrote:
> However, even after that fix I have to define BOOST_ROOT=/opt/local to find
> boost. For manual builds, if don't do PATH=/opt/local:$PATH then meson uses
> pkgconfig from homebrew and runs the wrong pkg-config. But with th
Thanks for all the really helpful comments! I'm also sticking
mlog.warning( ) comments into the meson code to find things, and I
figured out why the link isn't happening.
I have a fix to finding boost libraries with a -mt suffix in meson here:
https://github.com/mesonbuild/
On 2017-12-22, at 11:51 AM, Mojca Miklavec wrote:
>
> meson recently changed something in that respect, but I don't fully
> understand how that rpath-stuff works, so something needs to be fixed
> in either case).
It takes a moment to grok it.
Here is a 1 minute summary of all
Portfile years ago, and I was
> completely unfamiliar with the Portfile format yesterday, so I have a bit of
> learning to do.
Welcome to MacPorts :)
> One issue I'm running into is that meson isn't finding boost at the
> configure stage. It might be because its not looking for
Portfile years ago, and I was completely
> unfamiliar with the Portfile format yesterday, so I have a bit of learning to
> do.
>
> One issue I'm running into is that meson isn't finding boost at the
> configure stage. It might be because its not looking for libraries wi
y, so I have
a bit of learning to do.
One issue I'm running into is that meson isn't finding boost at the
configure stage. It might be because its not looking for libraries with
the -mt suffix. However, while I'm continuing to look into this, I
thought I'd ask what th
On 8 November 2017 at 17:29, Ryan Schmidt wrote:
>
> The port fails to build universal, so something is missing there.
I tried a super simple hello-world program with a meson build. Setting
CXXFLAGS='-arch i386 -arch x86_64'
works fine there, so it must be something specific
Hi,
On 8 November 2017 at 18:21, Rainer Müller wrote:
>
> I did not mean there is nothing else to do, but it seems simpler as what
> is needed for cmake. meson using ninja to build is the same as cmake
> using make. Just that ninja is an extra dependency as it is not assumed
> to
ht help to start with some list
>>> of packages that support it.
>>
>> meson even prominently documents the use case for packaging:
>> http://mesonbuild.com/Quick-guide.html#using-meson-as-a-distro-packager
>>
>> It seems like meson respects the usual environment v
On Nov 8, 2017, at 09:02, Rainer Müller wrote:
> On 2017-11-08 14:04, Mojca Miklavec wrote:
>> Yes, we should prepare a PortGroup for it, I didn't start anything
>> yet, but I could look into it. It might help to start with some list
>> of packages that support it.
&
On 2017-11-08 14:04, Mojca Miklavec wrote:
> Yes, we should prepare a PortGroup for it, I didn't start anything
> yet, but I could look into it. It might help to start with some list
> of packages that support it.
meson even prominently documents the use case for packaging:
http://
On 7 November 2017 at 19:18, Ryan Schmidt wrote:
> We have a port for meson, a new build system.
>
> The libhttpseverywhere portfile uses it, and contains a lot of code for
> dealing with it.
>
> Should we have a meson portgroup to abstract away these details? Has anyone
> w
We have a port for meson, a new build system.
The libhttpseverywhere portfile uses it, and contains a lot of code for dealing
with it.
Should we have a meson portgroup to abstract away these details? Has anyone
worked on that already?
I want to investigate using meson for glib2 but I don&#
43 matches
Mail list logo
