Cross platform portability is a major goal of the CopperSpice project. Autotools may be old but it still beats its competitors for portability to obscure platforms.
We have removed moc and added templates but it is by no means black magic. The complexities are below the surface and we worked very hard to create a clean API for developers.
Since you mention you are on MSVC which is a bit behind the curve in standards compliance, you may be unaware of the wonderful tools that C++11 now provides for generating simple and readable template error messages. We have made extensive use of static assertions for specifically this reason. The vast majority of errors are quite straightforward.
As a bonus, many conditions which are run time errors in Qt are caught and diagnosed at compile time in CopperSpice. I will take a compile error, however inscrutable, over a guaranteed runtime failure any day.
Well, unfortunately the fact the clang/llvm generates nice looking error messages doesn't help Windows developers using Visual C++ at all.
And obscure platforms - are you targetting those as a priority? That could explain your choice of build system. On the other hand, the obscure platforms tend to have old, noncompliant C++ compilers and STL, so I am not completely sure how is that going to work together with your C++11 requirement. For me an "obscure platform" would be something like an IRIX 6.5, Solaris or some embedded hardware. Good luck with requiring C++11 there.
Of course, you could be targeting an obscure platform in the sense that it is one of the few that actually ships with fully C++11 compliant compiler, but then good luck with wide adoption of your software ...
Re compile errors vs runtime errors - agreed, even though most runtime errors related to moc in Qt are things like connecting to non-existing slot. That generates only an error message in console/log, it is not a fatal error.
However, moc gets you faster compilation time (heavily templated C++ takes ages to compile - just look at Boost) and more readable/idiomatic code. And then there is the portability issue to older compilers - templates were traditionally the poster child for poor/incomplete implementations by the compiler vendors.
> Its a fork of Qt by a guy who wants to see how much cleaner you can make the framework using a modern version of the language
A very astute observation. Actually, it's a fork of Qt by a girl and a guy but the rest of your statement is spot on.
There is no way we could merge back upstream, but that is not because we forked from 4.8. It is because statements made by several key individuals in the Qt project indicate that our changes would not be welcome and they see no reason to remove moc.
Since CopperSpice is an open source project released under the GPL & LGPL, we are not looking to profit from it nor can we. Now, if someone throws money at us, we certainly will not refuse. But we did this for the love of the game.
We just found out about this thread 10 minutes ago, and we have been on reddit for the past 8 hours answering questions. We are stunned by the level of interest and feedback.
We have been using git from day 1 in house for our version control and that will be available to the public shortly.
We have been focusing on outreach to the local SF Bay area developer community, and we presented CopperSpice at the SF Bay Area Association of C/C++ users meeting in February. You are welcome to peruse the meeting notes and our slides:
Ok, I went through your presentation, it does give more background. Let me re-raise my concerns.
- You are based on Qt 4.x. Why? The 5.x branch is better in every respect (yes, bugs, but that's fixable). This project is breathing life into a version of the lib which really should be dead. I think this is a net negative for Qt.
- Why is this the first most of us in the Qt community hear about it? The project is basically coming out of nowhere, imposing itself as this shiny new thing when it has critical flaws and the only point of contact is an email address and a forum with 0 posts in it. Feels like it was developed in complete secrecy.
- (minor) Autotools build system, really? You're not going to get much respect about this from most Qt devs. Why not just use cmake?
- I'm concerned about the entire way this project came forward. You don't have a git repository. You claim you will but claiming things is easy - the question it immediately raises is why don't you have a git repository yet? (And this comes back to what I was saying earlier about developing this in secret).
The lack of a repository is the second most important issue after 4.x, I think. Git repos aren't just "the code". They're insight into how development happens (are commits clean and readable? is it easy to contribute?), insight into who contributes (is it a corp? how many people are working on this?), into whether upstream changes are being pulled down, etc.
I am not any of developer of this project , but for first concern I think most C++ bug fix'es can back ported very simply to 4.8, I think most of them already done by Qt itself.
We had everything set up on sourceforge and we hit the limits of what we could accomplish on sourceforge last month.
We have been moving everything including downloads and forums to a better location. We have not yet moved the git repo to a publicly accessible location, but this is in progress. Thank you for bringing this to our attention, and I apologize for the inconvenience.
We have removed moc and added templates but it is by no means black magic. The complexities are below the surface and we worked very hard to create a clean API for developers.
Since you mention you are on MSVC which is a bit behind the curve in standards compliance, you may be unaware of the wonderful tools that C++11 now provides for generating simple and readable template error messages. We have made extensive use of static assertions for specifically this reason. The vast majority of errors are quite straightforward.
As a bonus, many conditions which are run time errors in Qt are caught and diagnosed at compile time in CopperSpice. I will take a compile error, however inscrutable, over a guaranteed runtime failure any day.