While discussion with @hanatos about some AGX stuff we also came to the subject of display profiling under wayland
@Zamundaaa some observations from packaging:
TIL @Higgins is here as well! 
Hi! 
I actually came across the other thread because of something else I’m working on. Figured I’d chip in!
I was asked to refactor colordevice into C++ which I only got around to starting the weekend before last, so while done it’s still slightly messy and I apologize for that. Fixed the soversion issue, but it’s definitely not ready for the wild just yet. Need to solidify and document the API still.
yeah i just wanted to see if i can reproduce the build failures that hanatos saw 
if you and Xaver want i can set up some automated builds on build.opensuse.org with you.
haha let me please downvote this. c++ is such a !@#)* language and also it's a @#)*& idea to make libraries with c++ since the interface across dso boundaries can’t have stdc++ objects anyways (both sides of the fence might link slightly different stdlib and then the malloc/free will corrupt the heap.
re: build failure: i didn’t really try for long, i failed to tell cmake where my locally built colordevice files are and didn’t want to install system wide for my first tests and then the 10min timeslot i had was over. i’m confident i can make this work if i try…
@Higgins JFYI e3b0e16 fails to build after your restructuring. see url above.
I’ve been working on tonight to get it to work better with DisplayProfiler. Just pushed a few changes almost exactly when I received the notification for your email, heh. You might’ve caught a wonky commit. Try it again, it compiles locally currently.
Part of the reason you might have had trouble compiling both is because I had no idea this was going on until yesterday, at which point the refactor was done and DisplayProfiler was still using the old interface.
I made a pull request for Zamundaaa which should get it to compile. Once that’s accepted, you should be able to compile and run it.
Hey, I just work here. Take it up with management.
It was originally in C, but by request I refactored it.
48ad5bc still fails with
[ 2s] c++ -Icolordevice-info.p -I. -I.. -I../src -I/usr/include/libusb-1.0 -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++20 -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g '-DVERSION="0.1.1"' -MD -MQ colordevice-info.p/src_colordevice-info.cpp.o -MF colordevice-info.p/src_colordevice-info.cpp.o.d -o colordevice-info.p/src_colordevice-info.cpp.o -c ../src/colordevice-info.cpp
[ 2s] ../src/colordevice-info.cpp:15:10: fatal error: colordevice/colordevice.hpp: No such file or directory
[ 2s] 15 | #include "colordevice/colordevice.hpp"
[ 2s] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[ 2s] compilation terminated.
Pushed the fix, should compile now. Sorry about that, was testing something locally and it escaped.
I’ve been playing fast and loose with the library, wasn’t expecting it to enter packaging this soon.
I’ll set up a separate test environment in a VM and use that to compile in a controlled environment rather than the chaos which is my desktop. I have an uncommitted test directory for unit and functional tests, and I’ll start to make that a priority too.
ouch. i’m serious. c++ objects over dso boundaries is a safe way for getting into trouble. looking at your .hpp header unfortunately it looks like the API does in fact contain STL objects. this essentially means your library will only be able to work safely if it is compiled in statically, and recompiled when the user application is compiled, with the same version of the same compiler.
I should teach you the magic of osc build 
“Objections your honor, we do not like static linking”
ok colordevice package looks good now. but displayprofiler still fails
I’m not married to C++, and I will be the first to admit it is not my strong suit. I could easily revert it back to C, or (likely) refactor it again into Rust with a C and C++ FFI. I’m going to wait for Zamundaaa to weigh in on it first, I don’t want to keep bouncing back and forth and delay it further.
Soon. Maybe. Unless there’s a re-refactor.
Just to give you an idea. A few years ago we set up this:
It automatically triggers builds on git push
and if you want to reproduce a build failure locally you can have a working copy of the package locally and then build with e.g. osc build openSUSE_Tumbleweed
and you can easily see if anything you did breaks on any distro.
Cool! I’m gonna be offline for a bit (sleep then work) so I’ll poke at it later and see if I have any questions.
oops, will correct that.
If you try to link libstdc++ in your app while the rest of the system uses libc++, then that may indeed cause problems… but that’s on the level if rm -rf / --no-preserve-root of intentional messing things up.
If you use the same stdlib as your distro, then you’re safe. Compiler vendors take ABI stability quite seriously nowadays - and GCC for example has allowed you to mix and match libstdc++ versions for quite a while, so even when ABI is broken, there is no actual problem.
what if an user builds one part with clang and the other with gcc?
if your cmake/meson stack doesnt warn about this … it is kinda still up to you at least partially.
They’re actually ABI compatible afaik. I’ve built KWin with clang while KDE Frameworks were built with gcc before (both ending up using libstdc++), and everything was fine.
You also have to go out of your way to change compiler and stdlib in the first place. It’s not like this should ever happen by accident