-
Notifications
You must be signed in to change notification settings - Fork 278
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
contrib: add meson build #2464
contrib: add meson build #2464
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2464 +/- ##
=======================================
Coverage 62.04% 62.04%
=======================================
Files 102 102
Lines 22764 22764
Branches 11205 11205
=======================================
Hits 14124 14124
Misses 6433 6433
Partials 2207 2207 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Do you think it is needed to provide some documentation explaining how this file is supposed to be used? Or developers experienced with Meson (I am not) will manage to find out easily? |
meson is dead simple so probably not. unfortunately i broke my hand after this PR so any changes will have to wait. |
Sorry to hear that! Take care |
👇 Click on the image for a new way to code review
Legend |
@piponazo Updated. One hand typing is hard :) @eli-schwartz One issue I've noticed with the VSCode plugin is that it's not loading these ../../ files. |
a7e2199
to
373ca23
Compare
The build system isn't in the root of the project, it's in a subdirectory. The files that it isn't loading are files which are, as far as Meson knows, arbitrary files retrieved from the operating system -- not part of the project itself. So I'm not surprised that it mishandles this.
This will not work, since the WrapDB -- and in general, use as a subproject -- requires there to be a meson.build file in the root of the project. If it's a hard requirement to isolate the contributed meson.build files away from the project root, then it's possible to do what the zstd project does, and provide a minimal stub meson.build in This will probably not fix VSCode, and it still cannot be used in the WrapDB directly, but the way zstd works is that the WrapDB provides its own minimal stub meson.build, installs it into the project root, and has that load the "actual implementation files". Since the only thing that needs to be duplicated in both places is the stub loader, that means the actual important bits are tracked in the project's own git repository and doesn't need to be duplicated. Really though, that's sort of awkward. :/ Much simpler to simply place the meson.build in the project root, which also lets people use a wrapped subproject using git development versions of exiv2 for testing purposes. |
sure, but the intention is not to replace cmake. It's not up to parity yet. From my experience, people like CMake better. If no one has any objections, I'll move to the root directory. |
Sure, no problem. I'm simply observing that even for a build system which is documented as "unofficial, secondary, useful for embedding in other projects perhaps -- but should not be used by default for building the project", it probably still makes sense to launch that from the root directory. It's "just" two files, and the root directory doesn't seem to be focusing on "lean and mean" -- there's more than 10 text files in the root directory, two png images, a whole bunch of dotfiles for tool configuration, and 3 directories containing various aspects of testing. Two more won't really hurt, and users will enter through the README file anyway (and there be told to type In general I suspect that most software projects shouldn't have a steep tax on adding more files to the project root, as long as each file has a clear and distinct purpose. Unless the project specifically says otherwise. :) |
Sure, as long as you include the disclaimer/note in the main README as well? |
Fine for me too to have the meson files in the root of the project. I will give it a try once I see them there ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
READNE-meson
Slight typo in the name. :)
meson.build
Outdated
brotli_dep = dependency('libbrotlidec', disabler: true, required: false) | ||
if brotli_dep.found() | ||
deps += brotli_dep | ||
endif | ||
|
||
curl_dep = dependency('libcurl', disabler: true, required: get_option('curl')) | ||
if curl_dep.found() | ||
deps += curl_dep | ||
endif | ||
|
||
zlib_dep = dependency('zlib', disabler: true, required: get_option('png')) | ||
if zlib_dep.found() | ||
deps += zlib_dep | ||
endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a matter of curiosity, why do these need to be disabler: true
?
It only takes effect if the .found()
method returns false, but everywhere you seem to first check for that anyway.
Aside: if you do not use disablers, then it is safe to append them unconditionally to deps +=
. Not-found dependencies are no-ops by default and possess no compiler flags or linkable libraries, so they just do nothing when added... (that's why you also need to explicitly check .found()
and set EXV_HAVE_*
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It’s mostly a hack to get the later set calls to not work and have the cmake and meson config files be more sinmilar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The later set()
calls are "working" and produce #undef
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the difference is
> /* #undef EXV_HAVE_LIBINTL_H */
vs
> #undef EXV_HAVE_LIBINTL_H
Yeah I can’t type with one hand. |
21a44e3
to
43d1844
Compare
Added basic xmpsdk support. |
With some MinGW testing, I found some bugs. |
No idea how to fix this. Any ideas? ping @kmilos |
@piponazo I see a warning about a bad function cast: https://github.com/Exiv2/exiv2/blob/main/src/basicio.cpp#L370 Is there a point to this block? I would think std::filesystem is enough. |
@neheb Need to add Actually that might not work: https://stackoverflow.com/questions/11546403/importing-inline-functions-in-mingw so maybe it's better not to inline it at all? |
But then it doesn't compile. |
215bb92
to
79e4d17
Compare
Seems I need a hack to undefine max, |
2a7b9e4
to
9537009
Compare
Pull request has been modified.
5779ec6
to
ed83686
Compare
If requiring GCC8, it may make sense to also update to C++20. GCC8 supports that partially. |
This is a fairly basic meson file that builds only the library. Useful for stuff like WrapDB. Signed-off-by: Rosen Penev <rosenp@gmail.com>
Pull request has been modified.
This is a fairly basic meson file that builds only the library. Useful for stuff like WrapDB.
Signed-off-by: Rosen Penev rosenp@gmail.com