Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrap Entry Supersedes Presence of symlinked subproject #13746

Open
WillAyd opened this issue Oct 3, 2024 · 6 comments
Open

Wrap Entry Supersedes Presence of symlinked subproject #13746

WillAyd opened this issue Oct 3, 2024 · 6 comments

Comments

@WillAyd
Copy link
Contributor

WillAyd commented Oct 3, 2024

Describe the bug
When a project is symlinked into the subdirectory alongside a wrap file with the same name, Meson appears to ignore the symlinked subproject and proceed to using the wrap file entry

To Reproduce
I've created an MRE at this location - https:/WillAyd/meson-subproject-mre

The "main" project looks like:

project(
    'meson-subproject-mre',
    'c',
)

foo_lib = library('foo', 'foo.c')
foo_dep = declare_dependency(link_with: foo_lib)

In the "python" subdirectory, I've created a separate project that should refer to the "main" project:

project(
    'meson-subproject-mre',
    'c'
)

subproject = subproject('meson-subproject-mre')
foo_dep = subproject.get_variable('foo_dep')

Within the subprojects directory of the python directory, I have symlinked to the project root. However, I've additionally provided a meson-subproject-mre.wrap file in case that symlink does not work (ex: when installing from a Python sdist)

If you check out that project, then run:

cd python
meson setup builddir
meson compile -C builddir

You will see that meson downloads meson-subproject-mre from the wrap file, rather than resolving the project via the symlink

Expected behavior
Calls to subproject('meson-subproject-mre') should resolve through the symlink, rather than through the wrap system

system parameters
meson 1.5.2

@QuLogic
Copy link
Member

QuLogic commented Oct 3, 2024

I cannot reproduce with 1.4.1 or 1.5.2. Is this not on Linux?

Also, your symlink doesn't point to the top-level directory, but goes one above it and assumes the name of the top-level directory; could you perhaps have renamed it after making the symlink?

@QuLogic
Copy link
Member

QuLogic commented Oct 3, 2024

Oh, actually, you didn't provide a .wrap in the MRE, so it wouldn't have attempted it.

@WillAyd
Copy link
Contributor Author

WillAyd commented Oct 3, 2024

Ah sorry...missed pushing that. Should be there now

@QuLogic
Copy link
Member

QuLogic commented Oct 3, 2024

Ah, the problem is your wrap file says that the directory is meson-subproject-mre-$COMMIT_HASH, which isn't there, so Meson downloads it. I'm not sure if there's any documentation stating that the wrap file gets priority over a similarly named directory.

For now, you could get it to work by renaming the symlink a bit, and doing:

subproject = subproject('meson-subproject-mre-symlink', required: false)
if not subproject.found()
  subproject = subproject('meson-subproject-mre')  # Use wrap file.
endif

@WillAyd
Copy link
Contributor Author

WillAyd commented Oct 3, 2024

Ah, the problem is your wrap file says that the directory is meson-subproject-mre-$COMMIT_HASH, which isn't there, so Meson downloads it.

Oh OK - in this particular case I can just change that to remove the $COMMIT_HASH then too and it should work right? Seems to from a local test.

I was following that pattern since I've seen that in the wrapdb for many packages, assumedly to avoid a conflict of versions.

@QuLogic
Copy link
Member

QuLogic commented Oct 3, 2024

You could, but then you'd have to use a download URL from GitHub that doesn't include the commit hash in the resulting directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants