'"default-features": false' doesn't work with a dependency of a dependency(transitive dependency)

[fujiinzukaatusi]

Describe the bug
"default-features": false doesn't work when it's in vcpkg.json of a package that's a dependency of my project.

Edit:
For those who got to this issue, here's a summery.

• This behaviour is currently not considered as a bug.
• See this comment to grasp how the current implementation being.

Below is vcpkg.json of my projcet.

{
    "name": "my-project",
    "version-string": "0.1.0",
    "dependencies": [
        {
            "name": "osg",
            "features": [
                "fontconfig",
                "freetype",
                "plugins",
                "docs"
            ],
            "default-features": false
        }
    ]
}

"plugins" feature of osg package uses full features of gdal package. I changed osg's vcpkg.json to use only gdal's core feature.
Below is an extract of it.

"plugins": {
      "description": "Build most OSG Plugins",
      "dependencies": [
        "curl",
        {
          "name": "gdal",
          "default-features": false
        },
        {
          "name": "giflib",
          "platform": "windows"
        },
        {
          "name": "jasper",
          "default-features": false
        },
        "libgta",
        {
          "name": "libiconv",
          "platform": "windows"
        },
        "libjpeg-turbo",
        "libpng",
        {
          "name": "libxml2",
          "platform": "windows"
        },
        "tiff"
      ]
    },

Then I ran vcpkg install --triplet x64-windows-static --dry-run. I expected in the installation list gdal package containing only [core] feature.
But I got this:

Detecting compiler hash for triplet x64-windows...
Detecting compiler hash for triplet x64-windows-static...
The following packages will be built and installed:
  * brotli[core]:x64-windows-static -> 1.0.9#3
  * bzip2[core]:x64-windows-static -> 1.0.8#2
  * curl[core,non-http,schannel,ssl,sspi]:x64-windows-static -> 7.84.0#2
  * dirent[core]:x64-windows-static -> 1.23.2#1
  * egl-registry[core]:x64-windows-static -> 2021-11-23
  * expat[core]:x64-windows-static -> 2.4.8#1
  * fontconfig[core]:x64-windows-static -> 2.14.0#4
  * freeglut[core]:x64-windows-static -> 3.2.2
  * freetype[brotli,bzip2,core,png,zlib]:x64-windows-static -> 2.12.1#2
  * freexl[core]:x64-windows-static -> 1.0.6#1
  * gdal[core,curl,default-features,geos,hdf5,libspatialite,netcdf,postgresql,recommended-features]:x64-windows-static -> 3.5.1#6
  * geos[core]:x64-windows-static -> 3.11.0#1
  * getopt[core]:x64-windows-static -> 0#2
  * getopt-win32[core]:x64-windows-static -> 0.1#4
  * gettext[core]:x64-windows-static -> 0.21#9
  * giflib[core]:x64-windows-static -> 5.2.1#2
  * gperf[core]:x64-windows -> 3.1#4
  * hdf5[core,cpp,szip,zlib]:x64-windows-static -> 1.12.2#1
  * jasper[core,default-features,opengl]:x64-windows-static -> 2.0.33#6
  * json-c[core]:x64-windows-static -> 2022-06-26#2
  * libgeotiff[core]:x64-windows-static -> 1.7.1#1
  * libgta[core]:x64-windows-static -> 1.0.8#3
  * libiconv[core]:x64-windows-static -> 1.17
  * libjpeg-turbo[core]:x64-windows-static -> 2.1.4
  * liblzma[core]:x64-windows-static -> 5.2.5#6
  * libpng[core]:x64-windows-static -> 1.6.37#19
  * libpq[core,lz4,openssl,zlib]:x64-windows-static -> 14.4
  * libspatialite[core,freexl,geocallbacks]:x64-windows-static -> 5.0.1#7
  * libwebp[core,libwebpmux,nearlossless,simd,unicode]:x64-windows-static -> 1.2.4
  * libxml2[core]:x64-windows-static -> 2.9.14#1
  * lz4[core]:x64-windows-static -> 1.9.3#4
  * netcdf-c[core,dap,hdf5,nczarr,netcdf-4,platform-default-features]:x64-windows-static -> 4.8.1#2
  * nlohmann-json[core]:x64-windows-static -> 3.11.2
  * opengl[core]:x64-windows-static -> 2022-03-14#1
  * opengl-registry[core]:x64-windows-static -> 2021-11-17
  * openjpeg[core]:x64-windows-static -> 2.5.0
  * openssl[core]:x64-windows-static -> 3.0.5#4
    osg[core,docs,fontconfig,freetype,plugins]:x64-windows-static -> 3.6.5#15
  * pcre2[core]:x64-windows-static -> 10.40
  * pkgconf[core]:x64-windows -> 1.8.0#3
  * proj[core,net,tiff]:x64-windows-static -> 9.0.1#1
  * pthread[core]:x64-windows-static -> 3.0.0#1
  * pthreads[core]:x64-windows-static -> 3.0.0#11
  * qhull[core]:x64-windows-static -> 8.0.2#3
  * sqlite3[core,tool]:x64-windows -> 3.39.2
  * sqlite3[core,rtree]:x64-windows-static -> 3.39.2
  * szip[core]:x64-windows-static -> 2.1.1#9
  * tiff[core,jpeg,lzma,zip]:x64-windows-static -> 4.4.0#1
  * vcpkg-cmake[core]:x64-windows -> 2022-07-18
  * vcpkg-cmake-config[core]:x64-windows -> 2022-02-06#1
  * vcpkg-cmake-get-vars[core]:x64-windows -> 2022-05-10#1
  * vcpkg-pkgconfig-get-modules[core]:x64-windows -> 2022-02-10#1
  * vcpkg-pkgconfig-get-modules[core]:x64-windows-static -> 2022-02-10#1
  * vcpkg-tool-meson[core]:x64-windows -> 0.63
  * zlib[core]:x64-windows-static -> 1.2.12#1
  * zstd[core]:x64-windows-static -> 1.5.2#1
Additional packages (*) will be modified to complete this operation.

Environment

• OS: Windows10 x64
• Vcpkg version: 2022-09-01-dfb82802c8cc562ce3b665a904a65b22314de724

To Reproduce
See Describe the bug.

Expected behavior
See Describe the bug.

Failure logs
None.

Additional context
I already confirmed:

1. It works when my project is directly dependent on gdal.
2. Other features of osg don't use gdal because when I removed gdal from the dependencies of "plugins" it didn't appear any longer in the list.
3. Trying on curl while gdal is removed resulted the same. curl's full features were listed.
4. Installing osg in classic mode resulted the same.

[fujiinzukaatusi]

Sorry, I edited the bug description. "on that another package is dependent" wasn't really needed. It's simply "when it's in vcpkg.json of a package that's a dependency of my project".

[dg0yt]

IIRC you have to explicitly add a gdal dependency to your project manifest in order to control the gdal features.

[fujiinzukaatusi]

When my project uses A and A depends on B, I need to control B's features in my project's vcpkg.json?

[dg0yt]

Yes. Your project's manifest is the ultimate control if you don't want default features.
(And in classic mode, without user manifest, there is no control at all.)

[fujiinzukaatusi]

I'm afraid but my issue is that the "default-feature" statement is ignored while declared. There still seems being a problem even if that method works on controlling dependencies.

[dg0yt]

I'm afraid but my issue is that the "default-feature" statement is ignored while declared. There still seems being a problem even if that method works on controlling dependencies.

The default-features statement in the user project cannot take effect if a dependency depends on gdal without declaring "default-features: false". Unfortunately, this is the case for osg[plugins].

[fujiinzukaatusi]

The default-features statement in the user project cannot take effect if a dependency depends on gdal without declaring "default-features: false".

plugins feature doesn't apply "default-features: false" to gdal dependency in the original osg manifest. Now I'm using my local osg manifest that's modified to set "default-features: false" to gdal, then it seems ignored.
I'm arguing with default-features in modified osg manifest not my project manifest.

[fujiinzukaatusi]

I think this would be a bug of vcpkg tool rather than portfiles.
Does anyone have a clue how to fix it? I'm absolutely new to the codebase. Even only a hint where to look over will be appreciated.

[dg0yt]

@fujiinzukaatusi You should start with reading more existing issues and PRs (incl. PRs in vcpkg-tool repo).

[fujiinzukaatusi]

@dg0yt I saw some discussions including #11602 or #24548, but couldn't really get the point. Although #11602 was before introducing the manifest mode.
Could it happen to be considered correct that "default-features: false" in port manifest is ignored? If so, it's too weird for me.

[dg0yt]

Could it happen to be considered correct that "default-features: false" in port manifest is ignored? If so, it's too weird for me.

It is never ignored, but it works somewhat different than expected by the uninitiated.

For a port xyz, the primary control is when the user runs vcpkg install.

• In manifest mode, add port xyz with "default-features: false` to the your project's manifest.
• In classic mode, add xyz[core] to the list of ports in the command line.
• (In both modes, don't forget to also list the xyz features you need in additon to core.)

The ports' manifests work like this:

• Without "default-features": false, they make the default features mandatory dependencies.
  The user cannot opt-out of them.
  This is what was discussed here for osg[gdal]: it unconditionally pulled in all default features of gdal.
• With "default-features: false`, they enable user control over the default features of dependencies.
  If the user does not apply what I called "primary control", vcpkg will choose the default features.

It is not like all of us are happy with this. Even less with regard to host dependencies.

[fujiinzukaatusi]

With "default-features: false`, they enable user control over the default features of dependencies.
If the user does not apply what I called "primary control", vcpkg will choose the default features.

Do you mean I need more steps than only setting "default-features": false to stop vcpkg from installing the default features?

[dg0yt]

Do you mean I need more steps than only setting "default-features": false to stop vcpkg from installing the default features?

The specific osg[gdal] issue was fixed promptly with #26698. Assuming that you did update:

In manifest mode, you must declare "default-features": false and "features": [<desired features>] for dependency gdal in your project's manifest.
In classic mode, you must add gdal[core,<desired features...>] to the command line.

[fujiinzukaatusi]

You mean:

• When my project depends on A and A depends on B[core], I need to state not only A but also B with "default-features": false in my project's manifest.
• Then the default features of B won't be installed any more.
• However, this works only when B is stated with "default-features": false in A's port manifest. Otherwise, vcpkg will install the default features of B no matter B is stated with "default-features": false in my project's manifest or not.
• In short, "default-features": false in the port manifests only allow/not declare to control if vcpkg installs the default features, while the user manifest simply declares.

Right?

[dg0yt]

Right?

Yes. 👍

If A can be used with B[core], but lacks "default-features": false for B, than it is a bug in A.

[fujiinzukaatusi]

OK, I finally understand. Very thanks!
Could I also ask you why the current implementation is like so? I suppose this is quite confusing for the beginners such as me.
It seems #11602 (comment) is considered as a good description of the concept, but I couldn't figure out what is the advantage. I still think it's more acceptable that the manifest just declares the dependencies not being care if it's user's or ports'.
At least the current behaviour feels needing to be documented.

[fujiinzukaatusi]

Could I also ask you why the current implementation is like so? I suppose this is quite confusing for the beginners such as me.
It seems #11602 (comment) is considered as a good description of the concept, but I couldn't figure out what is the advantage. I still think it's more acceptable that the manifest just declares the dependencies not being care if it's user's or ports'.
At least the current behaviour feels needing to be documented.

Should I open new issue for this?

[pragmaxwell]

Just to chime in, I was really confused by this was well. Using the previous example MyProj > A > B, I would never have expected to need to specify features for project B (a transitive dependency.) How A specifies within its manifest to use B should be used for all downstream projects.

It makes me concerned that I have to copy paste the entire transitive dependency tree in my own project's manifest just to ensure I have the correct dependencies as each library author intended.

Similarly, I as a library author should be able to specify the configuration of a dependency that anyone using my lib will get. If I specify default-features: false in a dependency, I expect every consumer of my library to get that version of the dependency transitively, without needing to do anything.

This seems strictly incorrect to me.

[fujiinzukaatusi]

@pragmaxwell Indeed. Not only that this is confusing and superfluously complicated, but not documented or announced in any place. Most of users and even library authors may not know about.

[Brainy0207]

I just fell into the same trap. I was trying to opt-out of some default features in a dependency to reduce build size. I set default-features: false for my dependency, so basically I wanted A > B[core], but I got A > B[core,defaultstuff].

In classic mode I have to call vcpkg install A B[core] explicitely to get the intended behaviour.
In manifest mode I need to add the dependency again to my manifest with default-features: false.

I agree that this is confusing and complicated. Is it really intended, that i need to keep track of all my transitive dependencies and replicate them in my command/manifest? This seems utterly redundant and prone for errors.

Why not just collect the minimum set of features and install the dependency using that. If someone really wants the default features they can add the package to the commandline/manifest. It seems the current implementation is exactly the opposite of what people would expect.

[fujiinzukaatusi]

I really wonder why no one gives any answer or even hint to this question. Actually it seems like neglected.

[dg0yt]

Why not just collect the minimum set of features and install the dependency using that. If someone really wants the default features they can add the package to the commandline/manifest.

I really wonder why no one gives any answer or even hint to this question. Actually it seems like neglected.

The default features should reflect what upstream recommends, what most users want, and what should be tested best.

[fujiinzukaatusi]

The default features should reflect what upstream recommends, what most users want, and what should be tested best.

The default features may be so. I thought we've been discussing to avoid installing default features and get only core feature.

[dg0yt]

The default features may be so. I thought we've been discussing to avoid installing default features and get only core feature.

I don't get the point of this line.
The discussion has been about installing default features vs. core, in particular for transitive dependencies (aka "dependencies of a dependency".) AFAIU the vcpkg project owners take the point of view that even for transitive dependencies, the default features are what most users want. It is a reasonable POV. And you can opt out.

I would be happy if opting out could be done by a global switch. But that's another story. There is work in progress, but it seems to need more patience than advertising: microsoft/vcpkg-tool#538, microsoft/vcpkg-tool#177.

[fujiinzukaatusi]

The discussion has been about installing default features vs. core, in particular for transitive dependencies (aka "dependencies of a dependency".)

What I asked for is the reason why vcpkg basically installs default features of transitive dependencies even if defined it should get only core feature in manifests. The problem is not whether we can manually opt out them or not.

It's good there's such PR in progress, although I rather think it should be the default behaviour without switching. So could I recognise the PR is now not implemented due to technical or resource matters not any design reason?

[dg0yt]

why vcpkg basically installs default features of transitive dependencies while defined it should get only core feature in manifests.

I think this is a misunderstanding. In port manifests, "default-features": false doesn't mean: Ignore the dependency's default features. It rather means: The user can override the default features of the dependency. The port maintainer did sufficiently ensure that either core or the explicit set of features are sufficient for the given dependency. Often it really means extra work for the port maintainer. (And for most non-trivial ports, maintainers are just community members which contribute on a voluntary base.)

[fujiinzukaatusi]

I'm sure to already understand the current implementation. The question is why "default-features": false should have different meanings by where it's used, what the advantage that we can get by keeping such behaviour is. Because it seems only confusing or troublesome to me.

[silverqx]

Because Gentoo's emerge is doing this in the right way, I'm pretty sure about this, I've been using it for years and never had a problem with the use flags. Still, I can't compare portage with vcpkg but I'm trying to figure this out and what would be a good solution for this. And I'm pretty sure there is no simple solution for this right now.

[fujiinzukaatusi]

even if the pcre2 vcpkg.json states it as the default-feature: false.

If you want to install only core, there's the two requirements.
1."default-features": false in port manifest
2."default-features": false in user manifest
Both is necessary, if one is missed vcpkg installs the default features.

Even if bzip2 is defined with "default-features": false in pcre2 manifest, vcpkg installs the default features of bzip2 when not defined in user manifest.

[silverqx]

But take this dependency path, tinyorm -> qtbase -> pcre2 -> bzip2.

pcre2 states that it depends on bzip2 with disabled-features: false, nothing else depends on the bzip[tool], I looked all over if something needs this [tool] feature, and no one needs it.

But vcpkg logic is to install the bzip2[core,tool]. I would understand it if something else depends on this bzip2[tool] but no one needs it.

The default-feature: true is god here 😂 Compile everything by default is the way 😂

[silverqx]

@fujiinzukaatusi Also thank you for the clarification, advices, and suggestions

[fujiinzukaatusi]

@silverqx No worries. Just in case you still have got a question I'll leave the answer.

1."Isn't this behaviour a bug?"
->Some contributors said it's normal and efficient implementation for package management. But I don't think so then have been arguing it here.
2."Isn't there the solution to avoid this?"
->There's currently no easy solution but the manual replication of definition. Although the feature request and PR that can fix it is going on.
3."I can't still understand the behaviour."
->This would be all about it I can explain. I really agree it's too confusing but hope you figure out. Feel free to ask anything you can't get.

Actually I'm now using Conan instead and won't return back to vcpkg anymore until this problem gets solved.

[silverqx]

1."Isn't this behaviour a bug?"

I think that it's unfinished only, what is really bad is that the whole vcpkg repository with 2000 ports is based on this.

Although the feature request and PR that can fix it is going on.

It looks like it will never be merged, I looked at this.

I really agree it's too confusing but hope you figure out.

The biggest problem is that vcpkg documentation is not writing about this, there should be some paragraph in the default-features description that these features are totally ignored for deeper dependencies and that the dependency graph is not resolved and it should be written in the red alert box or admonition.

Actually I'm now using Conan instead

Noo, I don't know how to code in Python and use Python to manage CMake builds I don't know, I believe that conan is great but I will never use it.

Is also conan ignoring these features in deeper dependencies? How does this work in conan?

[dg0yt]

How should my application's manifest look like to install this tinyorm library

The most important thing wasn't mentioned AFAICS: listing qtbase with "default-features": false (and feature sql). For reference:

.\vcpkg.exe install --dry-run "qtbase[core,sql]" "bzip2[core]" "pcre2[core]"
Computing installation plan...
The following packages will be built and installed:
    bzip2[core]:x64-mingw-dynamic -> 1.0.8#5
  * double-conversion[core]:x64-mingw-dynamic -> 3.2.1#1
    pcre2[core,jit,platform-default-features]:x64-mingw-dynamic -> 10.42
    qtbase[concurrent,core,doubleconversion,sql,thread]:x64-mingw-dynamic -> 6.5.2#1
  * zlib[core]:x64-mingw-dynamic -> 1.2.1

(Edit, addition: Listing core at the command line is equivalent to listing "default-features": false in a manifest file.)

ignoring these features in deeper dependencies

It is not really ignored, but in port manifests it has different semantics: To enable control in user (application) manifest. The port author can signal that he really verified the minimal set of required features. If the user doesn't make explicitly declarations, the default remains to install the default features.
In above output, the pcre2 dependency in qtbase shows what it means when port authors don't declare that property: Despite me asking for pcre2[core], qtbase pulls in the default features of pcre2. They are assumed to be hard requirements. In contrast, for bzip2, the tools features remains omitted, despite being a default feature. The property is not ignored.
(Edit, long version:)
In above output, the pcre2 installation shows the consequences of the qtbase port authors not declaring the "default-features": false property on the pcre2 dependency: Despite me explicitly asking for pcre2[core] on the command line, qtbase pulls in the default features (jit,platform-default-features) of pcre2. Vcpkg tool assumes the default features to be hard requirements. In contrast, for bzip2, the tools features doesn't get installed when I ask for bzip2[core], despite being a default feature: For its bzip2 dependency, the pcre2 manifest has "default-features": false. This property in the port manifest is not ignored.

[silverqx]

The most important thing wasn't mentioned AFAICS: listing qtbase with "default-features": false (and feature sql)

I also understand it this way and I've been using the vcpkg install this way from the beginning, thx for your advice.

It is not really ignored, but in port manifests it has different semantics: To enable control in user (application) manifest. The port author can signal that he really verified the minimal set of required features. If the user doesn't make explicitly declarations, the default remains to install the default features.

Yeah, that is exactly how it is working, I still don't know if this is good or bad. What if the library or executable depends on a really deep graph with 100 dependencies, eg. 15 direct dependencies and these dependencies depend on another and another dependencies eg. 5 level deep, how the user can control this in his manifest that is unreal.

In above output, the pcre2 dependency in qtbase shows what it means when port authors don't declare that property: Despite me asking for pcre2[core], qtbase pulls in the default features of pcre2. They are assumed to be hard requirements. In contrast, for bzip2, the tools features remains omitted, despite being a default feature. The property is not ignored.

Unintelligible, I don't understand what you wrote.

[silverqx]

In above output, the pcre2 dependency in qtbase shows what it means when port authors don't declare that property: Despite me asking for pcre2[core], qtbase pulls in the default features of pcre2. They are assumed to be hard requirements. In contrast, for bzip2, the tools features remains omitted, despite being a default feature. The property is not ignored.

Even if it's unintelligible I think I know what you are talking about and it's this:

vcpkg install qtbase[core,sql-sqlite] bzip2[core] pcre2[core] --dry-run

Computing installation plan...
The following packages will be built and installed:
    bzip2:x64-windows -> 1.0.8#5
  * double-conversion:x64-windows -> 3.2.1#1
    pcre2[core,jit,platform-default-features]:x64-windows -> 10.42
    qtbase[concurrent,core,doubleconversion,sql,sql-sqlite,thread]:x64-windows -> 6.5.2#1
  * sqlite3[core,json1]:x64-windows -> 3.42.0#1
  * zlib:x64-windows -> 1.3

Because of that the vcpkg selected this set of features bzip2[core] and pcre2[core,jit,platform-default-features].

So even if the user/consumer states that he wants xyz[core] for some deeper dependency in his manifest or with the vcpkg install abc xyz[core] and the abc depends on some feature in the xyz port eg. xyz[core,jit] then the compilation never fails because the vcpkg takes this into account (this jit feature) and it's like a hard dependency as you described. And because of this, these features are not ignored that is what you meant?

[silverqx]

As you can see is not simple to think about this and even harder to write about it, it's not a piece of cake.

[fujiinzukaatusi]

@silverqx

The biggest problem is that vcpkg documentation is not writing about this, there should be some paragraph in the default-features description that these features are totally ignored for deeper dependencies and that the dependency graph is not resolved and it should be written in the red alert box or admonition.

What if the library or executable depends on a really deep graph with 100 dependencies, eg. 15 direct dependencies and these dependencies depend on another and another dependencies eg. 5 level deep, how the user can control this in his manifest that is unreal.

As you can see is not simple to think about this and even harder to write about it, it's not a piece of cake.

Indeed. Exactly.

Unintelligible, I don't understand what you wrote.

Probably they mean "default-features": false by 'property'. They are telling that "default-features": false in port manifests has the meaning that it enables "default-features": false in user manifest so it's ignored by default but not fully ignored.

@dg0yt

Yes, thanks. Then would you mean to keep occasionally emerging and explain this behaviour each time someone who's confused appears?

[github-actions]

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 28 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.

[fujiinzukaatusi]

This issue is not stale. Remove the label.

[silverqx]

I have another question related to this and I need a little help. vcpkg install is clear now and I know how to work with it.

All the following is classic mode related only.

But what about the vcpkg update or upgrade? Eg. I have installed qtbase[core,sql-sqlite] and these versions 6.5.2#1:x64-linux and 6.5.2#1:x64-linux-dynamic.

If I invoke the vcpkg ugprade it proposes me to rebuild qtbase with default features, how can I avoid rebuilding the whole qtbase with all default features and instead upgrade only the [core,sql-sqlite] features? Is this even possible?

I'm currently deleting the vcpkg folder and installing everything from clean, I didn't find any other solution.

Thx for suggestions and advices.

[dg0yt]

@silverqx This is a bug (probably regression) and should be is opened as a new issue: #34615. I can provide a simple reproducer:

git checkout HEAD~500 ports/tiff
./vcpkg x-set-installed tiff[core]
git reset HEAD
git checkout -- .
./vcpkg upgrade

[silverqx]

ok, thx

[silverqx]

Do you know how this problem relates to vcpkg manifest mode? What if I have installed some older version in manifest mode and then do git pull on the vcpkg repo and then try rebuild the project, vcpkg manifest mode calls the vcpkg install only internally, there is not vcpkg upgrade in manifest mode right?, how it picks newer versions and they features?

[silverqx]

I can't tell without testing, I would have to test this to verify it.

[dg0yt]

I can't tell without testing, but another run in manifest mode is more likely another equivalent to an explicit x-set-installed, not an equivalent to the upgrade command.

[silverqx]

I can't tell without testing, but another run in manifest mode is more likely another equivalent to an explicit x-set-installed, not an equivalent to the upgrade command.

I understand it this way too. Would be good to test it if it works correctly but I have too much work and I never noticed any problems related to this, I'm using manifest mode a lot.

[nadiaholmquist]

Is there any fix for this?

I need to disable the jit feature of pcre2 which is a dependency of qtbase because it's causing crashes, but there seems to be no way to do this short of actually modifying the port files for pcre2?

[dg0yt]

@nadiaholmquist Solve it as designed: Add pcre2[core] to the command line or add pcre2 with "default-features": false to the project manifest.

[nadiaholmquist]

That doesn't actually work, adding pcre2 to the project's manifest with default-features off gets it compiled with JIT anyway.

[dg0yt]

That doesn't actually work, adding pcre2 to the project's manifest with default-features off gets it compiled with JIT anyway.

Then we need to find the ports in your installed set which depend on pcre2 without "default-features": false, and fix those ports.

[dg0yt]

That doesn't actually work, adding pcre2 to the project's manifest with default-features off gets it compiled with JIT anyway.

Then we need to find the ports in your installed set which depend on pcre2 without "default-features": false, and fix those ports.

Well, almost all dowstream ports depend on default features here. (There was no such controlling feature until May 2023.)
You can still disable JIT with a custom triplet or an overlay port. But IMO any further assistance should start with a proper issue report for pcre2. (Where does jit fail?)