On 2/16/22 3:20 PM, Ted Felix wrote:
Wow, thanks for tracking all this down.
Thanks for the 3 decades of work that's gone into Rosegarden. :)
#4 seems best to me. So something like:
if(NOT ${CMAKE_VERSION} VERSION_LESS "3.13.0")
target_link_directories(rosegardenprivate
PUBLIC
${rg_OPTIONAL_LIB_DIRS}
)
endif()
Feel free to fork, make the change, test and send a merge request.
Will do. I had temporarily commented out the code in my working tree
despite being concerned about what the rg_OPTIONAL_LIB_DIRS are used
for. But if you're okay with ignoring them for cmake < 3.13.0 builds,
let's go for it.
You can also use the repo at github if you prefer.
https://github.com/tedfelix/rosegarden-official
Good to know. I have accounts on both sites but am a little more
comfortable using GitHub. At least until Microsoft decides to fully
assimilate it into Visual Studio and make it difficult or impossible to
use from other platforms. ;)
As for the Qt issue, that's my fault. Thanks for catching it. I
will fix it. We'll stay with supporting older Qt as we do have users
that need this.
That's a big relief. I had actually upgraded my cmake to solve the issue
there. (It wasn't trivial because my somewhat out-of-date distro doesn't
have a newer package available, but I cobbled something together.)
Qt was going to be a much bigger problem. Cmake has very few things
which rely on it, and it's only used for compiling code. I have 240
packages which depending on the Qt5 shared libs -- many of them critical
binaries in constant daily use -- so the chances of breaking my system
by hacking in an unsupported upgrade were significant.
I had figured your use of the new Qt (and cmake) features was
intentional or at least in accordance with development policies. Good to
know you're "holding the line" on dependency version-itis as long as
possible (breakage will eventually be forced by something or other).
I'd also hacked in things like:
#if QT_VERSION >= QT_VERSION_CHECK(5, 10, 0)
if (path2.back() != '/')
#else
if (path2[path2.size() - 1] != '/')
#endif
In the case of QString::back() and front() there's obviously not much
difference between using them vs their older operator[](int) or at(int)
substitutes. The source would be a little more readable, but I'd be
willing to bet that g++ compiles to the same executable code at anything
above -O0. But if you were going start using new features that were more
complex I wasn't looking forward to patching my local copies each time I
updated from the repository, or alternately begging you to accept a
merge with a bunch of ugly/obfuscating conditional compilation blocks.
Keep building with the older tools if you don't mind. Then we can
count on you to catch our mistakes.
Will do. I'll downgrade my cmake back to 3.10.2, stick with my libQt5*
5.9.7 version, and report back with any problems I come across.
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
