Build using meson?

[uni-dos]

I see that the project uses cmake to build itself. I find the syntax a bit challenging to understand, and I think meson is a bit more readable. I would be happy to add meson support to vkvg. I would just need a bit of guidance in translating cmake to meson.

[jpbruyere]

No problems, maybe the easiest way to get quick help is https://gitter.im/CSharpRapidOpenWidgets/Lobby?source=orgpage

[uni-dos]

I'll see if I can start the process this week.

[LinuxLegend]

@uni-dos Don't know if this will help you, but it isn't obvious when I was attempting to make meson file for vkvg that works on Linux, the problem is that GCC/Clang would have STRICT_ANSI__ defined and it break compilation for Vkvg with the missing pthread types and missing M_PI defines, and this can be fixed by adding compiler argument `-USTRICT_ANSI__`.

I hope this helps you if it matters at all.

[jpbruyere]

Yes, this is important. Under linux vkvg is compiled with the gcc option '-ansi', and it compile fine. What is your platform? Is it meson related only? The '-U__STRICT_ANSI__' solution looks not the best one, have you published your meson vkvg version so that I can make some tests by myself?

[uni-dos]

@LinuxLegend I haven't yet implemented meson into Vkvg just yet. I only added it to vkhelpers. I haven't really had the time to add more. I'll start again later this week.

[LinuxLegend]

I agreed that it probably not the best option to use -U__STRICT_ANSI__ though it was mentioned in stack overflow as one of the solution for the missing defines and pthread types:

https://stackoverflow.com/questions/61647896/unknown-type-name-pthread-barrier-t And that one other link I am still looking for.

Also I don't use C99 standard, but rather C17 standard and I explicitly cannot use the GNU C standards. This error comes up on Arch Linux (updated yesterday) on a x86_64 platform. I couldn't share the meson file since that is related to other closed source project, but generally, it includes the source code directly from vkvg/vkh with various defines mentioned in CMake copied over and configured, so I'll have to write up new Meson file for vkvg/vkh to see if this issue can be reproduced. The way I wrote for my Meson file was to not only compile Vkvg/Vkh object files, but also to generates LLVM IR for runtime compilation and optimization.

Here the errors I encountered when trying to work with Vkvg/Vkh in Meson Build.

I thought I'd help out by mentioning the issues and one of the solution to solving this if you come across this as I did. Also give me a moment to try and write up new meson file for Vkvg/Vkh.

[LinuxLegend]

Also for missing M_PI define, you can reproduce it on Arch Linux platform as followed:

test.c

#include <stdlib.h>
#include <stdio.h>
#include <math.h>

int main()
{
        printf("%f\n", M_PI);
        return 0;
}

build clang test.c -lm -ansi

It works fine if you omit the -ansi argument.

[jpbruyere]

Although I was trying to disable c extensions with cmake, compilation flags were still including 'gnu' exts, this made me missed several remaining M_PI instead of M_PIF in my code, M_PIF being defined in vkvg. So now, vkvg source should not complained anymore for missing M_PIF (committed on master: 5454492).

[jpbruyere]

For your pthread problems, it looks like tinycthread is trying to activate features not present in your c library (rwlock) , those locks are not used in vkvg (maybe in the future for the font cache). vkvg/vkh target c11. I've an arch linux, I will try to compile on it this afternoon.

[LinuxLegend]

Awesome! I am also almost finish with building a meson file for vkvg and vkh for you to test with.

[uni-dos]

@LinuxLegend did you have to move Vkvgs dependencies into the subprojects directory or did you manage to keep it the same?

[LinuxLegend]

Ok here it is, it isn't 100% finished, but got most of the way there and you can also check line 324 and uncomment it for disabling __STRICT_ANSI__. This should be reproducible on Linux and you can observe the issues with pthread with this.

Thank you again for looking into this!

meson.build

[LinuxLegend]

@uni-dos I move it outside of subprojects, because Vkvg is technically not a meson project yet. The meson.build above give you a little bit of an idea with vkh situation.

[uni-dos]

I see. Thank you for implementing the meson build. I don't have much experience writing a build system (still learning c and the meson build system). Let's hope we can work on this together. 😀

[LinuxLegend]

I'm looking forward to that! Just wanted to know what we should do about the pthread situation, I will try to finish up meson.build and then set up a branch on vkvg for us to collaborate/review on.

There are a lot of things I gotta add:

1. GLSL Shader compilation and inclusion
2. Test cases migration from cmake to meson
3. Double check on everything to see if I got all of the options/defines sorted out
4. Sort out the duplicate reference/functions in glutess for priorityq-heap.c file
5. Need to add at least 5 or 6 more defines from VMA options (in code defines such as VMA_DEFAULT_LARGE_HEAP_BLOCK_SIZE

[jpbruyere]

@LinuxLegend : Happy to see your interest in vkvg... :-). I succeed compiling on Arch, (got the pthread problems) by disabling vkvg-svg. The problem seems to come from the svg-viewer.c sample (compiled when cmake 'vkvg-svg=true'), it contains several includes that need double check for c11 conformance without extensions. I will still test your meson build today.

[jpbruyere]

Having tested your meson.build, I got the same problem. Need further investigations.

[LinuxLegend]

I set up a WIP Repo for VKVG: https://github.com/jpbruyere/vkvg/pull/119

Will work on it later tonight to try and finish up the meson.build file and have it ready when pthread bug can be addressed to finish up this issue.

[jpbruyere]

With cmake, reordering svg-viewer.c includes solves the pthread problem.

[jpbruyere]

Looking at tinycthread.h, I notice that it define some extension macros (_gnu, ..). tinlycthread is included in both vkvg and vkh with cmake, that should be why it compiles.

[LinuxLegend]

I have a question though, do we need tinycthread if we're already using C11 standard? By checking tinycthread website, it's mentioned that if c11 standard is unavailable on target compiler, then tinycthread would offer such replacement, but if both vkh and vkvg are already using C11 standard as explicitly defined in cmake, then do we even need tinycthread in that case? We could instead use #include <threads.h> avoiding such issues and it probably more portable as well due to using underlying compiler implementation handling this situation and plus the C Standard 11 been around for more than a decade, so it seems fairly apt to use threads.h going forward.

Relevant CMakes:

VKVG Cmake VKH Cmake TinyCThread Website

[jpbruyere]

@LinuxLegend that sounds good to me, I've recently started working on multithreading support, and due to windows incomplete support of c11, tinycthread seems a good option to quickly test vkvg with multithreading. I'll take some time to fully address this question in detail...

[LinuxLegend]

Wow, you're right about the issues with Windows, it seems C11 multi-threading support is classed as optional feature in Windows. And so I investigated to see if they ever gotten around to actually implementing threads.h in MSVC, they never did even though they said it was on their roadmap few years ago. I pasted the picture below to highlight their excerpt:

And currently in 2022, their feature table for C/C++ language conformance seems to indicates that threads.h support is still omitted. That's pretty frustrating considering Clang already have support for this on Linux and I see no reason why it couldn't work on Windows either.

I've also tried installing LLVM/Clang on Windows and try to build with threads.h and no luck either there. I'm pretty much hitting my head on the desk repeatedly... out of all problems that Microsoft have to contend with... threading is a show stopper for them for over a decade for some reasons.

[jpbruyere]

if clang implement c11 thread (I think it's the case) we could (as chrome for win does) compile vkvg on windows with clang. This could solve maybe plenty other multiplatform issues...

[LinuxLegend]

I tried that on Windows, it doesn't have threads.h on clang/clang-cl on windows after explicitly specifying C11 standard.

[LinuxLegend]

I guess we could use tinycthread.c as fallback on Windows and then use threads.h for other platforms like Linux and MacOSX to alleviate some of the issues.

[uni-dos]

@LinuxLegend I see that there is one meson build file. I was thinking of adding a meson build for each dependency of vkh, but that also seems to be a lot of unnecessary work. What do you all think?

[LinuxLegend]

I could split off vkh section of the meson.build in vkvg for vkh anytime since it's neatly organized.

[uni-dos]

Got it. Also, is the project name from your personal project? VMA at the moment seems to be a necessary dependency for vkhelpers. I have a meson build for vkhelpers here. I can move the vkh sections to it.

[LinuxLegend]

You could, but I would hold off a little bit, because I still need to sort out the installation stage for each dependency including VKH. At the moment, I am working on migrating test cases and setting up installation for those.

[LinuxLegend]

Just finish evaluating VKH, you can go ahead and proceed to do a split up on Meson build. I will rewrite Meson.build as soon as you finish VKH merge and VKVG Meson would import VKH Meson as a subproject dependency and we'll have to move VKH project over to subprojects/ directory per Meson Build convention.

Just don't forget the summaries at the bottom for VKH configuration. Just copy Directories, VKH Options, and VMA Options sections summaries.

[LinuxLegend]

We're pretty close to finishing up on Pull Request for VKVG Meson Build, just 3 tasks left and it should be good to go for review. I'll do a separate PR for fixing up VKVG Meson Build once VKH meson is sorted out.

https://github.com/jpbruyere/vkvg/pull/119

[uni-dos]

Would glutess and vkvg-svg still be in the external dependency or be moved to the subprojects as well? If that were to happen, the cmake build system would also need to be changed, right?

[LinuxLegend]

Only VKH needed to be moved into subprojects, glutess and vkvg-svg should be fine where they are under external folder. Subprojects are strictly for meson build convention.

[LinuxLegend]

Vkvg-svg might be moved into subprojects as well if we plan on making meson build for it too.

[uni-dos]

@LinuxLegend I have successfully compiled vkh with meson. It also seems like you updated the meson build and I will add those after I make sure it works on your system.

[LinuxLegend]

Yup, there are some significant changes like fixing options and few other things, sorry about that. Almost done though, just on the last leg of GLSLC shader compilation.

Make sure to check meson_options.txt as well

[uni-dos]

Thanks for your work! You've done what I wanted to do in a matter of days. I'll add the options later on and make a pull request.

[uni-dos]

I've submitted a pull request for vkh. I want to make sure it works properly.

[LinuxLegend]

Now the last step is the documentation, I think Meson.build is all ready to go. Have a look when able.

[LinuxLegend]

Whew, all done. I have set up PR for review now: https://github.com/jpbruyere/vkvg/pull/119

[LinuxLegend]

On side note, do we need to maintain both CMake and Meson build going forward? Just checking.

Reason for why I'm asking is that it may save us the trouble of maintaining separate build systems and I could write further documentation for how CMake projects can import VKVG Meson Build project with boilerplate code for CMake users.

[LinuxLegend]

Next thing on my list is that I need to backport a fix for Tinycthread issue by doing the followings:

1. Wait for initial merge for meson build on vkhelpers is concluded - https://github.com/jpbruyere/vkhelpers/pull/8
2. Add platform check in meson build for Vkhelpers to exclude tinycthread from the build if platform is not on Windows, instead the code will be using Threads.h provided by C11 standard, Windows is currently the outlier in this scenario.
3. Apply same change to vkvg for tinycthread.
4. Split up Meson build on vkvg to treat vkhelpers as a meson subproject going forward

[uni-dos]

May I ask why not keep pthreads and the windows specific threads?

[LinuxLegend]

It's so we don't have to write 2 separate code path and Tinycthread is basically a layer to translate Win32 Thread API over to Unix Thread API via Threads.h and C11 Standard provides that Threads.h outside of Windows, so it's basically just using Tinycthread for Windows since Windows never gotten around to supporting C11 Standard. Also the dependency("threads") handled the aspect of linking in pthread or Win32 thread if any.