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

chore(wrap): use wrap to manager subprojects #151

Closed
wants to merge 1 commit into from

Conversation

Decodetalkers
Copy link

If use wrap file , then we do not need to clone by ourself

As the project is using meson, meson can use wrap to manager subprojects, then we need not to use clone anymore

Log: use wrap file to manager subprojects

@any1
Copy link
Owner

any1 commented Aug 20, 2022

This does more than just adding wraps, for which there is already a PR. See #127

@Decodetalkers
Copy link
Author

Decodetalkers commented Aug 20, 2022

This does more than just adding wraps, for which there is already a PR. See #127

So it is better to find if there is system dependence first right?But I found that you use static to build target, not dylib..But the package in system should be dynamic , so find if there is system depends already is still needed?

Emm , or add option to control it is better?

If use wrap file , then we do not need to clone by ourself

Log: use wrap file to manager subprojects
@any1
Copy link
Owner

any1 commented Aug 21, 2022

In the current state of affairs, using the system libraries is the fallback. I.e. if no subprojects are found, the system libraries are used.

The current setup suits me well for development purposes and I don't mind that people have to take a few extra steps to build the project if they're building it themselves. It is very little work compared to the work that I've put in. Also, if you're building it yourself so that you can work on the project, then you'll probably want to set things up in a similar way that I have: with symlinks.

@Decodetalkers
Copy link
Author

In the current state of affairs, using the system libraries is the fallback. I.e. if no subprojects are found, the system libraries are used.

The current setup suits me well for development purposes and I don't mind that people have to take a few extra steps to build the project if they're building it themselves. It is very little work compared to the work that I've put in. Also, if you're building it yourself so that you can work on the project, then you'll probably want to set things up in a similar way that I have: with symlinks.

I think you are right, then I close this pr

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

Successfully merging this pull request may close these issues.

None yet

2 participants