Let's say I have Qt5 projects. Qt6 is released and I want to move my projects to it, but I want to have possibility to build my projects with Qt5 too. I know that Qt5 API is incompatible with Qt6. So my question is Qt6 API backward compatible with Qt5 API? If I will fix all issues to build with Qt6 will projects build with Qt5?
For example, in Qt6 there is no QVBoxLayout::setMargin() method but exists QLayout::setContentsMargins(). That means that Qt6 in this case is backward compatible with Qt5.
But do there exist possible underwater stones in backward compatibility with Qt5?
Compatibility isn't black-and-white. Majority of Qt 5 code (in terms of lines of code) is compatible with Qt 6, but some specific constructs you may use are not. That doesn't automatically make things "incompatible", since there may be other constructs you can use that will work in both Qt 5 and Qt 6. And furthermore, the degree of incompatibility that any particular project runs into highly depends on the project's scope, the idiomatic-ness of the design, etc.
In your current Qt 5 project, add the QT_DISABLE_DEPRECATED_BEFORE=0x060000 define to the project. This will disable all obsolete APIs you may be using. I imagine there'll be several errors that you'll have to fix. Read up on the code migration tools that may be available in Qt 6. This is a preparatory step: it won't make your code incompatible with Qt 5, it will just disable all the parts of Qt 5 that were removed in Qt 6 but for which there are cross-compatible alternatives that work in both Qt 5 and Qt 6.
Then, build the project under Qt 6 and see what the problems are. There are no changes needed to your qmake project file (most likely), but you'd need to select Qt 6 in the CMakeLists.txt if you use cmake.
Work around the problems in the simplest fashion at first - using preprocessor conditionals - you'll hopefully have to deal with only a few places where this is necessary.
Now that you have a project that builds and hopefully mostly works in both Qt 5 and Qt 6, you can evaluate whether you could refactor the code to come up with a cross-compatible variant, or perhaps you could factor out some methods/classes that abstract out the incompatible changes that you experienced, so the preprocessor defines will be concentrated in one module vs. sprinkled all over the place.
Short answer is no, Qt6 is not backward compatible with Qt5. There are, for example, difference with events system...
In Qt5 was QWidget::enterEvent( QEvent * ), whereas in Qt 6 there is QWidget::enterEvent( QEnterEvent * )...
Related
I have a visualbasic application that interacts with several versions of software (Catia)
The Visual basic code is common to all versions of Catia software but it only works if the dlls of the correct version are referenced.
Is it possible to reference the dlls of all Catia software versions in the app (they have the same name) and to use the correct dlls after having detected the software version.
I understand that you have a compiled .exe referencing the catia-api.
I encountered the same problems with our applications.
Two solutions that worked for me:
compile separate .exes for each catia release you require. Means:
have one catia release running, then compile. Repeat with next release.
The -regserver should be done by Catia when starting (which I am not 100% sure about, you might still need to do the -regserver as C R Johnson explained).
Use LateBinding which means do not reference any catia-dll/tlb at all. Instead use reflection to call api-methods. This is a lot more effort when developing your app, because you cannot use IntelliSense. (As a workaround you could develop with EarlyBinding in only one Catia release. When finished, change your code to LateBinding getting rid of all catia-api-references.)
I don't think there is any simple way to work around this.
If you have multiple versions you just have to run CNEXT -regserver (as admin) in the BIN folder of the version you want before CATIA is started.
Even this may not prevent problems, as libraries which change or disappear between versions and settings may not be compatible.
I'm writing a Windows Phone framework with Windows 8 in mind. That means I'm creating a Portable Class Library (PCL) to be used in both platforms.
Right now my PCL is targeting .NET 4.5, Windows Phone 8 and Windows Store apps, as you can see in the project properties.
In that project I need to use Path.DirectorySeparatorChar but I get the following error from the compiler:
System.IO.Path' does not contain a definition for 'DirectorySeparatorChar'
I understand that that particular char might be different in the different targeted OS (I really don't know if they are) but why is the compiler complaining about it? I mean, the property help doc says it is supported by .net framework 4.5, am I targeting the right framework? Is the PCL really targeting the full .net framework 4.5?
With respect to Path.DirectorySeparatorChar:
As far as I remember we've removed it from Windows Store in order to discourage manual parsing of paths. In general you should use Path.Combine() for assembling paths and Path.GetDirectoryName() for splitting them up. In order to check for invalid chars, there is another method that allows retrieving those.
So practically speaking, what do you need the property for?
Update: To answer your original question around understanding profiles: The profiles represent API intersections between the platforms you've selected in the PCL dialog. Generally speaking, the fewer platforms you target and the more recent the versions, the more APIs you get. Checking all platforms in the oldest version basically gives you the lowest common denominator.
Since you've targeted .NET 4.5 and .NET Windows Store, you can't access Path.DirectorySeparatorChar because that property isn't included in Windows Store.
So, here's the actual answer to this question taken from the MSDN forum.
When you are creating a PCL, you can only have a subset of API-s that are defined in that particular profile. A profile is a list of API-s visible in all platforms.
Now, even if some API exists in both individiual platforms, this doesn't mean that it will automatically be in the PCL profile. Why is it missing is anyone's guess, but you cannot infer those reasons yourself.
If you take a look at the official documentation on MSDN (Cross-Platform Development with the .NET Framework), you'll notice that there are several constraints on what can be shared. I guess that that particular property doesn't satisfy those constraints.
And a good way of knowing is a particular method is supported relies on the icons of the documentation
Your PCL can use .NET methods which are available to all of its targets. Since PathDirectorySeparator isn't available to Windows Store apps it isn't available in PCLs targeting Windows Store apps. You can see that it doesn't have the green shopping bag marker for store support at http://msdn.microsoft.com/en-us/library/system.io.path.aspx
I have looked into at least 6 different SQL Lua extensions, and they all seem to have their latest version compatible with up to version 5.1 of Lua. I have had zero success in implementing any of them into my current project which uses Lua 5.2, with the best case scenario ending in either silent program crashes or attempt to call global 'module' (a nil value).
I am not the original project owner, so I am trying not to be forced into changing the source code for it (though more recently, I have even gone down that road now).
And often times, it is unclear if these crashes are related to the way the project itself operates, the way the project implements Lua (as a static library), the way that Lua tries to implement it's extensions, the way the extensions implement their dependencies, a versioning conflict, or some sort of crazy combination of each. It's practically impossible to debug a silent crash in this manner, because the source of evil could literally be anything.
As the answer states in this question, I have even tried supporting the module function (which most lua sql extensions utilize, but was deprecated in 5.2), but the program still crashes or just complains about a seemingly infinite amount of missing dependencies. And after spending hours of tracking down (what would seem to be) all of the dependencies it would complain about, it still crashes.
Changing the project's source code to use the Lua 5.1 source appears to break the functionality of the project, resulting in various compiler errors regarding missing 5.2-related functions. Linking the MySQL C/C++ connector to the project results in rather vague runtime errors, which seem to conflict with the way the project implements Lua 5.2.
Are there ANY sqlite/MySQL extensions out there which actually work with Lua 5.2 on a 32-bit Windows machine? Preferably, "out-of-the-box" precompiled binaries with Lua source/ffi bindings?
OR alternatively, are there any clear instructions on how to get this set up properly, without having to scavenge through separate instructions across the web for each required assembly?
I am going through a major crisis here and i would like to ask for advices.
I have been developing a game the last couple of months which is entirely based on lua scripting. The project is a cocos2d based project with the inclusion of the mclua library (more about mcLua can be found here http://www.grzmobile.com/blog/2009/12/1/integrating-lua-into-and-iphone-app-part-2.html).
Now i am nearly at the end of the implementation of the project and i just found out that apparently the version of lua that i use which is 5.1.4 does not have a goto statement which is of great importance to this project. The latest version of lua 5.2 however supports now goto statements.
My problem is that when i tried to add the lua version 5.2 to my project the library mclua throws a bunch of errors and it seems that this library doesn’t work with any other version of lua other than 5.1.4.
What can i do about this now? I was supposed to be nearly at completion of the project. Does this mean i am completely screwed now ?
Then you have a choice to make. You may:
Stop doing whatever makse goto "of great importance to this project". I've used Lua for a while and I've never needed goto that badly. Whatever you're doing can be done in some other way.
Modify this "mclua" library to fix the "bunch of errors" you get when you try to link it against Lua 5.2. Since you didn't explain what these errors are, we can't really help you in solving them.
Note that Lua's minor version numbers are not intended to guarantee backwards compatibile with prior versions. While the changes are generally relatively small, that doesn't mean that effort was extended to make code work in both without modification.
I want to update/upgrade the standard Leopard install of Sqlite3 to >3.5 to use the new sqlite_xxx_v2 methods from a Cocoa project.
I can't seem to find any information on how to do this. Does anyone have any tips or a site that outlines the update procedure.
Also is 3.5+ supported on the iPhone. I understand it's embedded so shouldn't be an issue...
What you want to do is grab the amalgamation sources from http://sqlite.org/download.html . Then just compile that into / add it to your project. You don't want to replace the system sqlite- that'll have unintended consequences in other applications. Plus, I'm pretty sure the system sqlite isn't a stock sqlite... Apple has probably made their own modifications to it that core data relies on.
You can read up on the amalgamation stuff here: http://sqlite.org/amalgamation.html , but in short: '''The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3 and RTREE extensions'''
I'd also suggest not using the sqlite calls directly, they weren't designed to be used that way (says the author of sqlite). Instead, there are a number of cocoa wrappers out there, including fmdb: http://code.google.com/p/flycode/source/browse/trunk/fmdb/ (which I wrote) :)
-gus
You don't really want to upgrade the system version of SQLite on Mac OS X. The reason is that all Mac OS X software is qualified against the versions of the packages that it includes, as built by Apple's build process. Installing a different version of a package, or even building the same version yourself but doing so slightly differently than Apple does, may result in a system that behaves unexpectedly.
Finally, if you embed a newer version of SQLite — or any Open Source library or framework included with Mac OS X — into your own application, you should be sure to integrate the Darwin changes for it from Apple's public source site. That way you can be sure you'll get as close to the same behavior as possible from the library you've built yourself as the version Apple ships, which is especially important when it comes to functionality like file locking in databases.
I don't believe i've updated my version, but it's currently at 3.4.2, and i'm able to use the new methods with the current version.
And i'm running 10.5.5 with the latest (public) iPhone SDK.
It would likely be easier to just drop the library into your project and link it in from there.