Re: CMake | IPO: -f[no-]fat-lto-objects are not cross-platform GCC options (#25931)

You're welcome ... On Thursday April 25 2024 15:41:59 Sergey Fedorov wrote: >Wonder when this annoying bug is fixed: As you saw, it can help to provide a patch that fixes the issue. I have been dealing with CMake devs for quite a while and know they can be very convinced about their approaches

Fwd: CMake | IPO: -f[no-]fat-lto-objects are not cross-platform GCC options (#25931)

FYI: https://gitlab.kitware.com/cmake/cmake/-/issues/25931 (fix should land in the next release.) R.

Re: livecheck and curl 8.7.1

On Friday April 19 2024 22:10:40 Kirill A. Korinsky wrote: >Because MacPorts download distfiles and packages from HTTP, not HTTPS >because it contains checksums for that it downloads :) Nope. Maybe for distfiles that are hosted on the own servers, but the past few years more and more ports

Re: livecheck and curl 8.7.1

On Friday April 19 2024 20:51:20 Kirill A. Korinsky wrote: >"cleaner" approach is running dedicated instance of MacPorts which installs >only curl. Someone calls that "bootstrap" MacPorts. Maybe the cleaner approach to get the desired libcurl, but the end result is exactly the same. (One could

livecheck and curl 8.7.1

Hi, For a few years now I've copied libcurl.4.dylib and dependencies into $prefix/libexec/lib/pextlib1.0 and then use install_name_tool magic to ensure Pextlib.so uses this copy. This solves the problems with livechecks or even downloads failing because of unsupported SSL certificates on my

Re: inserting -stdlib=libstdc++ into cxxflags

BTW, did you ever run into trouble with libstdc++'s "new ABI" (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html) ? R.

Re: inserting -stdlib=libstdc++ into cxxflags

On Sunday March 17 2024 03:44:00 Sergey Fedorov wrote: >> but if libc++ 5 was maybe still a bit faster overall than libstc++ the >situation is now rather reversed though differences remain small I take that back, the differences aren't always small! I realised that the so-called "native"

Re: external build progress reporting cli utility?

>You can run the build under screen / tmux. Sure, but that only works if you think about it before launching it. And I only know `screen` as a utility to run multiple commands/sessions from a single shell, a more advanced for of the Ctrl-Z, bg and fg shell commands. What I'm thinking about is

external build progress reporting cli utility?

Hi, Does anyone else ever launch a substantial build on the "local console" and then leaves the Mac, but would like to monitor progress remotely sometimes from a simple SSH remote connection? I do, and wonder how difficult it would be to be able to do something like `tail -f `port logfile

Re: inserting -stdlib=libstdc++ into cxxflags

On Wednesday March 13 2024 03:44:17 Sergio Had wrote: >Which OS are we talking about? 10.9.5 but that what matters here is that it's a libc++-based OS version. >Building against libstdc++ is broken for Intel Not from what I can tell; I test built an OLD libxmlxx copy against libstdc++ from

inserting -stdlib=libstdc++ into cxxflags

Hi, I've been tinkering a bit with a personal GCC12 build patched to use libc++ by default, and now find myself unable to build against libstdc++. `configure.cxxflags-append -stdlib=libstdc++` appears to be filtered out somewhere in the "base" bowels, and `configure.cxx_stdlib libstdc++`

Fwd: Re: [MacPorts] #69411: ld64-latest upgrade time?

A quick heads-up to anyone with an interest in the linker (and who wasn't aware of the ticket yet). R. --- Forwarded message: Date: Monday March 11 2024 Subject: Re: [MacPorts] #69411: ld64-latest upgrade time? #69411: ld64-latest upgrade time?

gatekeeper overhead during builds and libtool

Hi, Does anyone else notice significant overhead from the gatekeeper daemon (or however it's called on more modern versions of the OS) during builds? This seems to be linked to intensive use of the libtool script. One of the ports where this overhead is very clearly visible is Mesa; I suspect

Really strange permissions errors

Hello! I'm trying to understand a weird permissions related error that a user of one of my custom ports is getting and I cannot yet reproduce. In a nutshell: this port uses an automatically generated subport (a "devport") for which I create the destroot as part of the main port's

Re: `port archive` ?

On Wednesday October 25 2023 06:05:45 Eric Gallager wrote: >Yes, conflicts registered in the Portfile. For example: >---> Computing dependencies for arm-elf-gcc3 >Error: Can't install arm-elf-gcc3 because conflicting ports are >active: arm-elf-gcc >Error: Follow

hack'a'day :accessing macports:: variables from a PortGroup

Hi, This is probably seen as a forbidden hack, but is there a way to access variables from the macports namespace in a PortGroup (or Portfile)? I know that "user" code like this is executed under/through `mportopen` which is in that namespace, but when I invoke `namespace children` I only see

Re: `port archive` ?

FWIW, I'm now using `port archive` in my "devport" PortGroup, so that updating the main port and the companion devport with developer content doesn't re-activate that content if the user deactivated it. (It still gets installed normally otherwise.) R.

Re: `port archive` ?

On Monday October 23 2023 01:34:03 Eric Gallager wrote: >I sometimes try using the `port archive` command, and one thing I'm >wondering about it is, why does it bother calculating conflicts if it >doesn't actually install the port? That's strange, in my experience conflicts are detected when

Re: "devports"

On Saturday October 21 2023 14:27:26 René J.V. Bertin wrote: >Anyone feel like kicking these tyres with me? :) Too late, but there's code to kick to see what errors I've grown! It was an interesting little exercise, relatively easy to implement by letting the archive unpack take place in a

Re: `port archive` ?

On Sunday October 22 2023 19:38:46 Rainer Müller wrote: >Yes, 'port archive' would do what you are looking for. You are correct >this is actually missing in port(1), but please see the separate man >page port-archive(1). Thanks, and strange. That's exactly what I did, or thought I did (came up

"devports"

Hi, I know this comes up once in a while, and how it's non-trivial to integrate with MacPorts's way of doing things: "dev ports" that contain the developer/ment resources corresponding to (usually) a library. These can be very useful to prevent blocking or at least awkward situations in case

`port archive` ?

Hi, It happens that I'd like to "install" a variant of a self-built port without actually activating it (e.g. when libraries are in use and I have no immediate need to activate that different variant). Looking through the code I saw there must exist a `port archive` command that isn't

Re: [MacPorts] #68136: cross-platform portfiles and shlib extension

> Why would a port need that? It would be up to the build system to know how > to build libraries for each platform. Who said anything about the build systems? Have a look at the path-style depspecs used in many ports!

accessing $argv0 from Portfile?

Hi, Is there a way to get the path to MacPort's tclsh interpreter from within a Portfile, other than by using a `glob` to find it in $prefix/libexec/macports/bin ? (not to do anything naughty, just to run a Tcl test/benchmark.)

libc++ with ParallelSTL (pstl)?

Hi, Working on my own port:libcxx to upgrade it to 13.0.1 I noticed that there's an intriguing possibility to build it to use ParallelSTL - and that happens to be a "runtime" that's included in the source tree. Does anyone have experience with this feature? It does require an extra dependency

self-building libobjc?

Hi, I've been tinkering a bit with DYLD_INSERT_LIBRARIES, DYLD_FORCE_FLAT_NAMESPACE and the MacPorts libc++, on OS X 10.9.5 . Some applications crash at startup. While that may be because of simply forcing a flat namespace the crash reporter does mention that libobjc.A.dylib is being loaded

Re: path:-style depspec to libc++.dylib?

On Monday May 08 2023 12:41:08 Kirill A. Korinsky wrote: >and it works as expected. FWIW, my attempt also worked for things like `port info` and IIRC even `port fetch`; I got the error when I tried `port configure`, when "base" actually tries to use the depspec data.

Re: path:-style depspec to libc++.dylib?

On Monday May 08 2023 12:41:08 Kirill A. Korinsky wrote: >I just tried > >depends_lib path:lib/libc++.dylib:libcxx > >and it works as expected. Interesting. I am not at the right machine right now but I was tinkering with the legacy-support 1.1 PortGroup, where it adds a dependency

path:-style depspec to libc++.dylib?

Hi, I tried to write a path:-style depspec to libc++.dylib, but that gives me a regexp compilation error. Can that be avoided by escaping those pluses in the filename and if so, how? A simple backslash didn't do it for me. Thanks, R.

Re: reinplacing -Wl,-foo,bar to "-foo bar"?

On Wednesday April 26 2023 17:13:22 René J.V. Bertin wrote: >I'll probably get there, but in anyone has the magic formula handy I'd >appreciate it. NM, figured it out. BTW, this was part of developing a PortGroup that provides an alternative for ports which need rust and cargo in order to be

reinplacing -Wl,-foo,bar to "-foo bar"?

Hi, This is a little problem I'm grappling with on Linux, but it could be of interest for others. I need the set `configure.ld` to the actual linker (say $prefix/bin/ld) because that's what the build system in question expects (here: rustc) because it passes flags that aren't understood by gcc

dbus: legacy vs. current plist locations

Hi, I've been running a customised port:dbus for years now, that I've never updated (because 1.10.12 ain't broke...). Looking at where things are being installed currently I see some significant differences in the install location of the launchd plists. Has there been an automatic transition

configure step downloading resources - supported on buildbots?

Hi, Exploring Audacity's latest code I notice it requires the conan package manager nowadays, for building "vendored" libraries. A number of those aren't in MacPorts. >From what I've seen this downloaded stuff goes into `build.dir` but I seem to >recall that the build bots don't support

trac preview annoyance

Hi, I've started noticing (a euphemism...) browser page scrolling when the trac preview updates, not systematically but sufficiently frequently to be very annoying e.g. when it happens when you're just about to reposition the cursor. I don't know if this is due to an update to trac or to my

Re: what's with the C++ extension?

On Monday September 19 2022 18:41:54 Chris Jones wrote: >Note though the expose of that feature, on newer systems at least, is very >much limited at the moment and I stand by my statement that mixing multiple >c++ runtimes, unless done very very carefully, is a recipe for problems. So

Re: what's with the C++ extension?

never mind, I discovered port:macports-libcxx and the trac ticket that led to its creation (which mentions the filesystem extension...) The port does exactly what I think should be done, but at a port-specific level. R.

Re: what's with the C++ extension?

On Monday September 19 2022 13:56:01 Chris Jones wrote: >But anyway, I m sure you will think you are right, so please feel free to >experiment on your own system, as you get to own the pieces there once it >breaks. What do you think happens when you upgrade an OS but not ALL your other

Re: what's with the C++ extension?

On Sunday September 18 2022 23:57:53 Chris Jones wrote: >Follow the above at your own risk. As I said, there is no need to update the system libc++ on systems that already have it; `port:libcxx` can (could) provide a set of libraries under ${prefix} that override the system ones for dependent

Re: what's with the C++ extension?

On Sunday September 18 2022 14:29:07 René J.V. Bertin wrote: >On more recent systems that have a stock libc++ one can install `port:libcxx` >with the binaries under $prefix . I have been doing that for years so all >MacPorts executables use it, and that has never caused any ABI issues with

Re: Disabled key in launchd plists

On Sunday September 18 2022 00:55:59 Ryan Schmidt wrote: >I don't think I have anything further I want to add to this conversation. I've >explained to the best of my knowledge how launchd/launchctl work and what >MacPorts does with its launchd support and why. I'm sure you can perform any

what's with the C++ extension?

Hi, Building C++ code that does #include I get either a file-not-found error or a bunch of errors that the functions are 10.15+ only. What's with that? If the implementation is provided by libc++, isn't this something that could be patched? Shouldn't require any external dependencies on

Re: Disabled key in launchd plists

Ryan Schmidt wrote on 20220916::21:30:28 re: "Re: Disabled key in launchd plists" >My reading of the documentation is that the system will start any launchd >plists at system startup time that are in the standard LaunchDaemons >directories and that are not disabled. That's possible, but it

Re: Disabled key in launchd plists

On Thursday September 15 2022 10:07:24 Ryan Schmidt wrote: >Apple's default value of Disabled is false, which means (according to the >documentation I read) that the service will be started automatically the next >time the system starts up Or the user logs in, for agents. That's what I thought

Disabled key in launchd plists

Hi, I've noticed that most of the launchd plists installed by ports have `Disabled: true`. There are a select few that don't, among which the mariadb server. I have that port installed, and yet no mariadb launchd job loaded which suggests that launchd does not auto-load plists, at least not

Re: "LinuxPorts and machista

René J.V. Bertin wrote on 20220715::00:04:04 re: ""LinuxPorts and machista" >I seem to recall that I am less alone nowadays in actually using an adapted >version of MacPorts on Linux (or *BSD)? During a spell of hilarious mood I decided to refer to those in (Portfile & patch) code as

"LinuxPorts and machista

Hi, I seem to recall that I am less alone nowadays in actually using an adapted version of MacPorts on Linux (or *BSD)? One of the things I miss on Linux is the rev-upgrade feature, if not only because it is also very useful to figure out who depends on a given shared library. Anyway, has

How about a MacPorts "system" (generic) python port?

--- Forwarded message: Date: Thursday July 14 2022 Subject: Re: [MacPorts] #65478: glib2, glib2-devel, glib2-upstream: only has a build dependency on python?! Ticket URL: Comment (by ryandesign): > The ticket is

gobject_introspection and meson

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 activated.

Re: +universal for x864+arm64 on Macintel

On Wednesday June 15 2022 17:10:01 Christopher Jones wrote: >what about configure.universal_archs though, have you set that to have > 1 >entry ? thats what base cares about, hence the "due to < 2 supported >universal_archs A! That works, indeed. It seems that this variable is empty when

Re: +universal for x864+arm64 on Macintel

>Base is exactly smart enough. When supported_archs contains only 1 arch, it >does make sense to offer a universal variant, therefore base prevents it. As I said before, supported_archs contains x86_64 and arm64. If ports should be able to create a universal variant in case that variant

Re: +universal for x864+arm64 on Macintel

On Monday June 13 2022 04:34:46 Ryan Schmidt wrote: >The standard universal variant has no content. (Universal support is >implemented by adding the return value of procedures like >[get_canonical_archflags cc] to CFLAGS.) Many ports implement their own >universal variant by manually creating

Re: +universal for x864+arm64 on Macintel

On Monday June 13 2022 17:54:06 Ryan Schmidt wrote: >There is no support in MacPorts base (or via a portgroup) yet for using such >an SDK; it would have to be programmed into the port manually. I had submitted >a PR to add such support to base, but it proved to be incomplete and I did not

Re: +universal for x864+arm64 on Macintel

On Monday June 13 2022 21:40:19 Chris Jones wrote: I did indeed misread; I should have realised that 10.11 predates ARM Macs by too much. >Macports only supports buidling against the sdk you would ‘naturally’ get >installing the Xcode/CLT version supported on a given OS. Whilst it might be

Re: +universal for x864+arm64 on Macintel

Ryan Schmidt wrote on 20220613::04:34:46 re: "Re: +universal for x864+arm64 on Macintel" >As far as I know, the SDK would also need to support arm64, which SDKs prior >to macOS 11 don't. Therefore MacPorts doesn't support compiling for macOS for >arm64 prior to macOS 11. What Apple call the

Re: +universal for x864+arm64 on Macintel

On Monday June 13 2022 02:48:06 Ryan Schmidt wrote: > (and if MacPorts does not create a universal variant automatically in this > case then the port should do so itself) Doh, I should have thought about that. Still, it would be more elegant to handle that situation with something like

+universal for x864+arm64 on Macintel

Hi, Just an observation: When I tried to test the new +universal variant of a x864_64 + arm64 port (port:VLC) installing from official DMGs on my 10.9.5 Mac I discovered that the variant wasn't added because the port only supported the current build architecture. Whaaat? It took me a while to

typo in the cargo_fetch PG?

Hi, In cargo_fetch.1.0.tcl::cargo._old_macos_compatibility, shouldn't the bail-out test be for `${os.platform} ne "darwin" || ${os.major} >= 12` instead of the current combined condition? R.

Re: OWL - wayland for mac

On Tuesday November 30 2021 11:30:26 Robert Tillyard wrote: >It would be nice if this was an option as we currently rely on the ability to >run over TCP/IP and serve X11 out from the server to the client devices. You'd need xwayland for that if I understand correctly, but that should become

port:libcxx - why so old

Hi, Judging from the version number, port:libcxx ships a version that's long outdated. Is there a reason for that, like it's the latest version that builds on all OS X versions that require the libc++ conversion? I have a local version that is currently at v8.0.0 on my 10.9.5 system and have

Re: python PortGroup and destroot.pre_args

On Friday July 02 2021 04:31:50 Ryan Schmidt wrote: >If I create a dummy portfile that includes the python portgroup then then >immediately tries to print destroot.pre_args, it shows why it failed: Yes, I followed that much. >The real question is why do you need to access destroot.pre_args

python PortGroup and destroot.pre_args

Hi, There's a strange side effect of the Python PG on `destroot.pre_args` (and maybe other, related variables). Accessing the variable after including the PG leads to {{{ DEBUG: Sourced PortGroup python 1.0 from /path/to//_resources/port1.0/group/python-1.0.tcl DEBUG: can't read "name": no

Re: depends_run and activation

On Wednesday March 17 2021 06:53:53 Ryan Schmidt wrote: >I think your proposal would result in a lot of unnecessary activations of >older dependencies which could have consequences for other ports. Without versioned dependencies would be helpful t avoid that (e.g. in Debian you can indicate a

Re: depends_run and activation

On Wednesday March 17 2021 05:28:29 Ryan Schmidt wrote: >I don't believe we can do that because I don't believe that information is >stored in the registry. Probably not, given that MacPort doesn't do versioned dependencies. In itself that doesn't mean that it couldn't store the versions of

Re: depends_run and activation

On Tuesday March 16 2021 23:12:12 Ryan Schmidt wrote: >There is no such thing as a "too-new version". There is only one version of a >port available in the ports tree -- the current version. Sure, but anything that's in the current port tree should not be authoritative over what is currently

Re: depends_run and activation

On Monday March 15 2021 08:00:10 Ryan Schmidt wrote: >On Mar 14, 2021, at 07:51, René J.V. Bertin wrote: > >> Supposing runtime dependencies are stored in the registry, > >Yes of course. > >> wouldn't it be possible and a good idea to give at least a warning if any >> are missing when you

depends_run and activation

Hi, Supposing runtime dependencies are stored in the registry, wouldn't it be possible and a good idea to give at least a warning if any are missing when you (re)activate a port? I presume you would already have gotten a warning when DEactivating the dependency, but that can have been long

Re: [MacPorts] #54752: cmake 1.1 PG : ccache support

> In the cmake-1.1 PortGroup, where this is all handled, I don't see that > the appropriate configure args are ever actually added to the > configure.pre_args list. That's done via the `cmake::ccaching` procedure. I can confirm that `CMAKE__LAUNCHER` works with the make and ninja generators. >

Re: [MacPorts] #58729: legacy-support missing futimens() (and utimensat)

> That actually leads to an interesting observation: no file system I know > of that is writable on OS X actually supports sub-second time precision > (other, than, MAYBE... NFS and SMB?) Have you tried ZFS?

Re: [MacPorts] #58729: legacy-support missing futimens() (and utimensat)

> You can test back as far as 10.9, right? I can too, just let me know if and when.

default_variants and variant conflicts

Hi, I still have some recurrent problems with variants and causality/serialness. I'm now developing a set of Python variants (mutually exclusive) for a port, declared and defined programmatically and with the latest python version as the default variant. I don't really understand but can

Re: "publishing" Tcl support functions used in Portfiles?

On Monday September 07 2020 22:39:50 Joshua Root wrote: Hi, >You do it like this: > > >In that proc, $mport is an identifier that was returned from mportopen, >and the code being executed in the

Re: "publishing" Tcl support functions used in Portfiles?

On Monday September 07 2020 22:39:50 Joshua Root wrote: Thanks, will have a look. >You do it like this: > > >In that proc, $mport is an identifier that was returned from mportopen, >and the code being

"publishing" Tcl support functions used in Portfiles?

Hi, This may be considered a "not-done" but please bear with me and give me some pointers on how it might be done locally... Suppose you have developed a Tcl function in a Portfile (or a PortGroup) that performs a necessary job which you might sometimes want to be able to perform outside of a

Re: admin user (and ditto group member) no longer has the corresponding permissions?!

On Tuesday July 28 2020 00:15:22 Clemens Lang wrote: >Don't do that, that completely breaks the privilege separation. You >might as well use a non-root install then. Not at all. It who the macportsuser is changes nothing for the usual case of installing binary packages nor for the normal case

admin user (and ditto group member) no longer has the corresponding permissions?!

Hi, (Cross-post - apologies - explanation below) To streamline things as a port dev/maintainer I've set `macportsuser` to myself, which means that as a member of the admin group I get to do a lot of things without needing to sudo all the time. I know the risks, and always managed to avoid

Re: [MacPorts] #51083: update: port:qgit

I guess I'll have to take a look... When starting via the cli, did you use a full path to the bundle exec? If I had to guess at this point I'd wager that "they" tried to build a nice, standalone app bundle and either failed, or else there was something in my port that interferes (though I

`port edit` and ^Z in remote shells

Hi, I've been noticing a weird and rather annoying anomaly I thought I'd share here to see if anyone has an idea why it happens. NB: I don't think it's a bug in MacPorts. I often work remotely on my Mac, sometimes ssh'in in from my Linux rig, more often launching a terminal emulator from my

Re: control verbose mode in Portfile?

Christopher Jones wrote: > If you want pass a message on to the user, you should not use verbose output > to do that. Instead just use a regular ‘ui_msg' Except that this is not what I'm after; `port -v` generates additional output to what's printed via `ui_msg`, just like `set -x` shows more

upgrading self-built MacPorts and version management

Hi, I've just upgraded my Linux adaptation of MacPorts's master branch, where I was helped greatly by the fact I use the system package manager (after doing a -reinstated- `port dpkg MacPorts-devel`) because it allowed me to revert to the previous version when I ran into a glitch I had

control verbose mode in Portfile?

Hi, Out of curiosity: is it possible to control verbose mode in a Portfile, like with `set +x` / `set -x` in shell scripts? I'd be interested to use that in the post-activate block of a number of my ports, as an easy way to give a little more feedback to the user. Thanks, R.

Re: invalid certificate chain during port-fetch

Thanks Mojca. Looking at the quoted ticket I see that I did propose the idea there back in 2016, so maybe I did write the patch after all. Doesn't really matter. What does matter is that it should be possible to pull a similar trick with libcurl itself provided it is conservative enough in the

Re: invalid certificate chain during port-fetch

On Saturday December 28 2019 21:51:07 Ryan Schmidt wrote: >If I understood the patch correctly, it adds a fallback so that if fetching >via the curl library fails, then it tries fetching via the curl command line >program. To my knowledge MacPorts has never had code for using the curl >command

Re: invalid certificate chain during port-fetch

On Saturday December 28 2019 14:10:29 Ryan Schmidt wrote: >> but don't understand why the fallback doesn't work on Mac. Maybe a different >> exception is raised there? >> >> Anyway, I think the fallback makes sense in this kind of situation, and it >> should handle bootstrap errors gracefully.

Re: invalid certificate chain during port-fetch

On Friday December 27 2019 21:32:26 Ryan Schmidt wrote: Hi, Thanks for looking into this! >You didn't mention what instructions you're referring to Only because there are several threads about this issue on S-E and I was on a different machine when I wrote to the ML.. And you must have seen

Re: suggestion: samurai

A QtWebEngine rebuild in the same build.dir (without preceding `make clean`) completed just fine using ninja symlinked `samu` (a part of the tree was rebuild). Samu is also able to build ninja itself (if you skip the ninja bootstrap procedure and copy samu to ${worksrcpath}/ninja). Here's an

Re: suggestion: samurai

PS: an alternative solution for the ninja issue outlined in my OP would be a wrapper script like this {{{ #!/bin/sh if [ "${NINJA_JOBS}" != "" ] ;then exec ninja.bin -j "${NINJA_JOBS}" "$@" else exec ninja.bin "$@" fi }}}

suggestion: samurai

Hi, I just discovered a potentially interesting alternative to the ninja build tool: https://github.com/michaelforney/samurai: samurai is a ninja-compatible build tool written in C99 with a focus on simplicity, speed, and portability. I have yet to investigate and compare it, but the main

invalid certificate chain during port-fetch

Hi, Any suggestions how I can work around this kind of error (on OSX 10.9.8)? {{{ ---> Attempting to fetch kcontacts-19.08.3.tar.xz from https://download.kde.org/stable/applications/19.08.3/src % Total% Received % Xferd Average Speed TimeTime Time Current

depends_run and circular deps

Hi, Just had another run-in with a circular dep issue so I'd like to re-raise a question I think I've asked before: Why are runtime dependencies pulled in *before* building a port? Consider a port App for an application that requires a platform plugin. The plugin is a separate project that

Re: WTB Qt 5.12LTS (port:qt512) (attn mcalhoun)

On Sunday November 17 2019 08:30:36 Marcus Calhoun-Lopez wrote: >I am very sorry I cannot find the reference because this is the same argument >I made. No problem for the reference, it doesn't really matter who objected and exactly why. As far as I'm concerned you could just have introduced a

Re: WTB Qt 5.12LTS (port:qt512) (attn mcalhoun)

On Sunday November 17 2019 08:30:36 Marcus Calhoun-Lopez wrote: >The rebuttal was that we can port any such changes to the newer Qt. >Just to be clear, this was not my argument, but I went with the consensus. Did they also offer to do the porting? >> BTW, I'm getting reports of Qt 5.9.8 build

Re: WTB Qt 5.12LTS (port:qt512) (attn mcalhoun)

On Sunday November 17 2019 07:03:50 Marcus Calhoun-Lopez wrote: >Unfortunately, I cannot find the reference, but the consensus was essentially: >if the newest version works on all the platforms that the LTS does, then there >is no reason to keep another Qt port around. Hmmm, I think there is.

WTB Qt 5.12LTS (port:qt512) (attn mcalhoun)

Hi, May I ask why Qt 5.12LTS isn't in MacPorts, for those users who prefer stability or want to develop against a stable version? And in general, suppose it did exist: how good is the support for installing port:qt51x manually and then getting the corresponding dependencies on the correct,

Re: libicu-le-hb.0.dylib: undefined symbol: _ZTIN6icu_657UObjectE

On Tuesday October 29 2019 16:21:53 Chris Jones wrote: >Not really. > >Maybe it would help if you gave more details on how to try and reproduce what >you see... > For now, all I can say is that I'm trying to get a working icu-le-hb install, building with port:clang-5.0 and against

libicu-le-hb.0.dylib: undefined symbol: _ZTIN6icu_657UObjectE

Hi, After upgrading my ICU ports on Mac OS X 10.9 I'm getting the above error when trying to load libicu-le-hb.dylib . {{{ > demangle _ZTIN6icu_657UObjectE _ZTIN6icu_657UObjectE -> "typeinfo for icu_65::UObject" }}} As far as I can tell the 3 ports involved were all build using C++11 (and

Re: legacy-support and Wayland

Chris Jones wrote: Sorry, missed your reply. I guess what I'm asking is: the legacy-support package/project must have come into existence because of an interest in running code that requires functions not present in all Mac OS versions - does that interest cover Wayland too? I think that at

legacy-support and Wayland

Hi, A quick question to the legacy-support devs: do you have any interest in whether or not these support functions (plus whatever else is needed and doable) could help building Wayland for Mac? FWIW, I brought up the idea of running Wayland with Jeremy H. back when he was still maintaining

Re: scope of configure.optflags, configure.compiler etc. command line variables

On Friday September 20 2019 18:27:49 Ryan Schmidt wrote: >It would seem that making `port clean` delete the ccache caches would defeat >all current use cases of it. Not necessarily. AFAIK build commands under MacPorts almost always use full paths to source files because of the way configure

Re: scope of configure.optflags, configure.compiler etc. command line variables

On Thursday September 19 2019 20:20:06 Ryan Schmidt wrote: > > You could increase the size of your cache. > >Storing a separate cache for each port would quickly eat up a lot of disk >space. Evidently, but - ccache doesn't use more space than needed - the ccache directory compresses extremely

Re: scope of configure.optflags, configure.compiler etc. command line variables

On Monday September 16 2019 16:26:12 Ryan Schmidt wrote: >There should be no need for you to specify anything ccache-related on the >command line. You can enable ccache globally in macports.conf. Individual >ports can disable it if they are not compatible with it. Yes, I realised that after

  1   2   3   >