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

contrib: add meson build #2464

Merged
merged 2 commits into from
Feb 6, 2023
Merged

contrib: add meson build #2464

merged 2 commits into from
Feb 6, 2023

Conversation

neheb
Copy link
Collaborator

@neheb neheb commented Jan 16, 2023

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

@neheb neheb marked this pull request as ready for review January 16, 2023 01:08
@codecov
Copy link

codecov bot commented Jan 16, 2023

Codecov Report

Merging #2464 (f1e54c9) into main (e309680) will not change coverage.
The diff coverage is n/a.

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

@piponazo
Copy link
Collaborator

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?

@neheb
Copy link
Collaborator Author

neheb commented Jan 16, 2023

meson is dead simple so probably not. unfortunately i broke my hand after this PR so any changes will have to wait.

@piponazo
Copy link
Collaborator

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

@ghost
Copy link

ghost commented Jan 26, 2023

👇 Click on the image for a new way to code review
  • Make big changes easier — review code in small groups of related files

  • Know where to start — see the whole change at a glance

  • Take a code tour — explore the change with an interactive tour

  • Make comments and review — all fully sync’ed with github

    Try it now!

Review these changes using an interactive CodeSee Map

Legend

CodeSee Map Legend

@neheb
Copy link
Collaborator Author

neheb commented Jan 26, 2023

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

@neheb neheb force-pushed the meson branch 2 times, most recently from a7e2199 to 373ca23 Compare January 26, 2023 01:26
@eli-schwartz
Copy link
Contributor

@eli-schwartz One issue I've noticed with the VSCode plugin is that it's not loading these ../../ files.

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 is a fairly basic meson file that builds only the library. Useful for stuff like WrapDB.

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 contrib/meson/ and have that do a subdir() into the actual implementation files.

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.

@neheb
Copy link
Collaborator Author

neheb commented Jan 26, 2023

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.

@eli-schwartz
Copy link
Contributor

eli-schwartz commented Jan 26, 2023

sure, but the intention is not to replace cmake. It's not up to parity yet. From my experience, people like CMake better.

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 cmake).

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. :)

@kmilos
Copy link
Collaborator

kmilos commented Jan 26, 2023

If no one has any objections, I'll move to the root directory.

Sure, as long as you include the disclaimer/note in the main README as well?

@piponazo
Copy link
Collaborator

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 ;)

Copy link
Contributor

@eli-schwartz eli-schwartz left a 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
Comment on lines 48 to 85
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
Copy link
Contributor

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_*).

Copy link
Collaborator Author

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.

Copy link
Contributor

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.

Copy link
Collaborator Author

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

@neheb
Copy link
Collaborator Author

neheb commented Jan 26, 2023

READNE-meson

Slight typo in the name. :)

Yeah I can’t type with one hand.

@neheb neheb force-pushed the meson branch 2 times, most recently from 21a44e3 to 43d1844 Compare January 26, 2023 20:44
@neheb
Copy link
Collaborator Author

neheb commented Jan 26, 2023

Added basic xmpsdk support.

@neheb
Copy link
Collaborator Author

neheb commented Jan 26, 2023

With some MinGW testing, I found some bugs.

@neheb
Copy link
Collaborator Author

neheb commented Jan 27, 2023

../include/exiv2/xmp_exiv2.hpp:401:28: warning: 'Exiv2::Xmpdatum::operator=' redeclared inline; 'dllimport' attribute ignored [-Wignored-attributes]
inline Xmpdatum& Xmpdatum::operator=(bool value) {

No idea how to fix this. Any ideas? ping @kmilos

@neheb
Copy link
Collaborator Author

neheb commented Jan 27, 2023

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

@kmilos
Copy link
Collaborator

kmilos commented Jan 27, 2023

@neheb Need to add EXIV2API to both redeclarations on lines 401 and 406 I think.

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?

@neheb
Copy link
Collaborator Author

neheb commented Jan 27, 2023

But then it doesn't compile.

@neheb neheb force-pushed the meson branch 2 times, most recently from 215bb92 to 79e4d17 Compare January 29, 2023 21:58
@neheb
Copy link
Collaborator Author

neheb commented Jan 29, 2023

"cl" "-Iexiv2-1.dll.p" "-I." "-I.." "-I..\include\exiv2" "-I..\xmpsdk\include" "-I..\subprojects\expat-2.5.0\lib" "/MDd" "/nologo" "/showIncludes" "/utf-8" "/Zc:__cplusplus" "/W2" "/EHsc" "/std:c++17" "/permissive-" "/Od" "/Zi" "-DEXIV2API=__declspec(dllexport)" "/Fdexiv2-1.dll.p\src_basicio.cpp.pdb" /Foexiv2-1.dll.p/src_basicio.cpp.obj "/c" ../src/basicio.cpp
../src/basicio.cpp(663): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(663): error C2062: type 'unknown-type' unexpected
../src/basicio.cpp(663): error C2059: syntax error: ')'
../src/basicio.cpp(831): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(831): error C2062: type 'unknown-type' unexpected
../src/basicio.cpp(831): error C2059: syntax error: ')'
../src/basicio.cpp(832): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(832): error C2062: type 'unknown-type' unexpected
../src/basicio.cpp(832): error C2059: syntax error: ')'
../src/basicio.cpp(1080): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(1080): error C2062: type 'unknown-type' unexpected
../src/basicio.cpp(1080): error C2059: syntax error: ')'
../src/basicio.cpp(1110): warning C4003: not enough arguments for function-like macro invocation 'max'
../src/basicio.cpp(1110): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(1110): error C2144: syntax error: 'unknown-type' should be preceded by ')'
../src/basicio.cpp(1110): error C2660: 'Exiv2::RemoteIo::Impl::getDataByRange': function does not take 0 arguments
../src/basicio.cpp(1032): note: see declaration of 'Exiv2::RemoteIo::Impl::getDataByRange'
../src/basicio.cpp(1110): note: while trying to match the argument list '()'
../src/basicio.cpp(1110): error C2144: syntax error: 'unknown-type' should be preceded by ';'
../src/basicio.cpp(1110): error C2059: syntax error: ')'
../src/basicio.cpp(1110): error C2059: syntax error: ')'
../src/basicio.cpp(1110): warning C4003: not enough arguments for function-like macro invocation 'max'
../src/basicio.cpp(1110): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(1118): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(1118): error C2062: type 'unknown-type' unexpected
../src/basicio.cpp(1118): error C2059: syntax error: ')'
../src/basicio.cpp(1243): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(1243): error C2062: type 'unknown-type' unexpected
../src/basicio.cpp(1243): error C2059: syntax error: ')'
../src/basicio.cpp(1261): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(1261): error C2062: type 'unknown-type' unexpected
../src/basicio.cpp(1261): error C2059: syntax error: ')'
../src/basicio.cpp(1457): warning C4003: not enough arguments for function-like macro invocation 'max'
../src/basicio.cpp(1457): warning C4003: not enough arguments for function-like macro invocation 'max'
../src/basicio.cpp(1457): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(1457): error C2062: type 'unknown-type' unexpected
../src/basicio.cpp(1457): error C2589: '(': illegal token on right side of '::'
../src/basicio.cpp(1457): error C2059: syntax error: ')'
../src/basicio.cpp(1457): error C2143: syntax error: missing ';' before '{'
[13/94] Compiling C++ object exiv2-1.dll.p/src_convert.cpp.obj
[14/94] Compiling C++ object exiv2-1.dll.p/src_datasets.cpp.obj
ninja: build stopped: subcommand failed.
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: C:\ProgramData\Chocolatey\bin\ninja.EXE -C D:/a/exiv2/exiv2/build
Error: Process completed with exit code 1.

Seems I need a hack to undefine max,

@neheb neheb force-pushed the meson branch 3 times, most recently from 2a7b9e4 to 9537009 Compare January 30, 2023 01:02
piponazo
piponazo previously approved these changes Jan 30, 2023
.github/workflows/meson.yml Outdated Show resolved Hide resolved
meson.build Show resolved Hide resolved
@neheb
Copy link
Collaborator Author

neheb commented Jan 31, 2023

Sure, it's doable, but IMHO it's completely legitimate to say we require C++17 and GCC 8 on main/next version in order to have a clean code base and reduce maintenance burden.

If requiring GCC8, it may make sense to also update to C++20. GCC8 supports that partially.

piponazo
piponazo previously approved these changes Feb 6, 2023
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>
@neheb neheb merged commit 8d3e0d6 into Exiv2:main Feb 6, 2023
@neheb neheb deleted the meson branch February 6, 2023 21:45
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.

4 participants