migration to cmake results in corrupt binaries

django.Reinhard

@mchinand said in migration to cmake results in corrupt binaries:

Try setting the CMAKE_ARCHIVE_OUTPUT_DIRECTORY CMAKE_LIBRARY_OUTPUT_DIRECTORY for the plugin sub-projects

Already tried that without success.
Actually I use a custom command which calls a shell script, but the custom command is not always executed :(

@kshegunov said in migration to cmake results in corrupt binaries:

... instead of providing install interface(s) ... sigh

I do not know where I provoked your mockery. After all, I'm not a professional. I'll try my best, but after all, most is just guessing.

I thought, installing means publishing the build-results to user space - and that's not what I want here.
I used dest directories to have all in place for debug sessions, where I have paths coded in my application, where I search for plugins.

mchinand

You can install to any directory you want, it doesn't have to be a system directory. For testing, it can be one of your local directories.

kshegunov

@django-Reinhard said in migration to cmake results in corrupt binaries:

I do not know where I provoked your mockery. After all, I'm not a professional. I'll try my best, but after all, most is just guessing.

Yeah, I'm not a professional either, but I've wasted time dealing with people's overwriting of the build directories, so it's sort of a sore spot. Just follow the documentation is my best advice.

I thought, installing means publishing the build-results to user space - and that's not what I want here.

Well, not exactly no; what @mchinand said.

django.Reinhard

@kshegunov said in migration to cmake results in corrupt binaries:

dealing with people's overwriting of the build directories

Yes, last few days I did lot of stupid errors - including wiping out my complete project tree. But that happens if working too long.

@kshegunov said in migration to cmake results in corrupt binaries:

I thought, installing means publishing the build-results to user space - and that's not what I want here.

Well, not exactly no; what @mchinand said.

That leads to the next problem. Using DESTDIR with qmake just moves the targets to given location and its transparent to QtCreator.
Starting debug just takes the binaries from DESTDIR.

With cmake that's not possible. And I fear, using install with qmake would not change a bit.
I found no way to change path of the executable to run/debug in QtCreator. It just takes the target.
Using cmake - ignores custom commands, which may create a different target or move it ...

So I have to use kdevelop, where I can attach the debugger to whatever binary.

django.Reinhard

@Christian-Ehrlicher said in migration to cmake results in corrupt binaries:

I coded the dependencies like this:

You don't need this at all with a recent build system - as soon as a library links against another one, those deps are created automatically.

After reading that, I thought - why not give qmake another try.

So I removed all that coded dependencies and did a fresh rebuild. Than I changed a source of a library and started rebuild.

Result: the changed source was compiled and that lib was rebuild. That was all!

no relinking of executable (which uses that lib)
no relinking of plugins (which use that lib)

So if qmake should be able to handle dependencies, what am I doing wrong?

On the other side: cmake does the expected work.

compiles the changed source
rebuilds the library
relinks the application
relinks every plugin that depends on that library

So from my point of view, there's a huge difference.

Beside from that:
Both debug builds produce slightly different sizes:
qmake:

executable about 43 MB
plugin about 33 MB

cmake:

executable about 35 MB
plugin about 28 MB

my very personal impression: qmake built is significantly faster

Christian Ehrlicher

@django-Reinhard said in migration to cmake results in corrupt binaries:

So if qmake should be able to handle dependencies, what am I doing wrong?

Where did I say that qmake handles this automatically? I would never call qmake a 'recent build system'...

The difference in the generated output size and also in the compile time results from different compiler options.

django.Reinhard

Hi Christian,

@Christian-Ehrlicher said in migration to cmake results in corrupt binaries:

Where did I say that qmake handles this automatically? I would never call qmake a 'recent build system'...

So I got you wrong. As you replied to my qmake dependencies coding. I did that as mentioned in Qt docs.

So if qmake is not a 'recent build system', what are you using?

@Christian-Ehrlicher said in migration to cmake results in corrupt binaries:

The difference in the generated output size and also in the compile time results from different compiler options.

Well, I did compare both build-systems command lines and I did not find any usage of compile options, which influence code generation (like -O2 or so). The main difference regarding code generation is the usage of different compiler names.

qmake uses g++
cmake uses c++

I can debug both binaries, so its not the difference between debug and release

kshegunov

@django-Reinhard said in migration to cmake results in corrupt binaries:

Yes, last few days I did lot of stupid errors - including wiping out my complete project tree. But that happens if working too long.

I didn't mean you personally. But anyhow.

That leads to the next problem. Using DESTDIR with qmake just moves the targets to given location and its transparent to QtCreator.
Starting debug just takes the binaries from DESTDIR.

With cmake that's not possible. And I fear, using install with qmake would not change a bit.

The build system already knows where the binaries are located. They're in the build folder where it'd placed it.

I found no way to change path of the executable to run/debug in QtCreator. It just takes the target.

Which target? There may be multiple targets, and so you can select in the interface which one you want to run.

Using cmake - ignores custom commands, which may create a different target or move it ...

It ignores no commands. I'd venture to say you're using it incorrectly; more specifically that you're trying to make it behave as you expect, instead of vice versa.

So I have to use kdevelop, where I can attach the debugger to whatever binary.

Which is again incorrect. I attach to running binaries no problem with Creator.

django.Reinhard

@kshegunov said in migration to cmake results in corrupt binaries:

It ignores no commands. I'd venture to say you're using it incorrectly; more specifically that you're trying to make it behave as you expect, instead of vice versa.

Allow me to ask an important question first: do you use cmake or do you just talk like that?

I've been struggling with cmake for over a week now and for me there's a big gap between cmake-documentation and what does work, or does not work for me. I'm tired fighting.

That's why I now settle for what does, even if I'm anything but happy with the status quo.

Meanwhile I found out how to debug a different executable with qtcreator. Popup-dialog is misleading :(

Actually I use a custom command to do some kind of install after build but inside the build tree. I execute a simple shell script and there I know what to do.

If you're using cmake, maybe you can help me with my last issue (regarding build system):

how can I add the language-files so that qtcreator knows them as part of the project (like he does with qmake projects)

Last comment to different file sizes: I changed cmake to use g++ - but that did not change filesize. So I suppose, cmake-build is still missing some action, that qmake does. Any idea, how I could find out, what is missing?

kshegunov

@django-Reinhard said in migration to cmake results in corrupt binaries:

Allow me to ask an important question first: do you use cmake or do you just talk like that?

Yes, I do use it, and also I just talk like that (in that manner).

I've been struggling with cmake for over a week now and for me there's a big gap between cmake-documentation and what does work, or does not work for me. I'm tired fighting.

Yeah, I feel you. I never said it was easy. The docs are decent if you're after a reference, but decent examples that are up to date and/or tutorials are n't much to be found.

That's why I now settle for what does, even if I'm anything but happy with the status quo.

That's fine by me in any case. Actually for what it's worth qmake is simpler and I like it more (also because I'm more used to it).

Actually I use a custom command to do some kind of install after build but inside the build tree. I execute a simple shell script and there I know what to do.

Eh, what I said before, why not add a target to do that instead of using some external shell script?
Also for cmake there may be better ways, depending on what exactly "some kind of install" means.

If you're using cmake, maybe you can help me with my last issue (regarding build system):

how can I add the language-files so that qtcreator knows them as part of the project (like he does with qmake projects)

Does that help:
https://doc.qt.io/qt-5/qtlinguist-cmake-qt5-add-translation.html

Qt adds a decent amount of macros/functions to cmake to make life easier.

Last comment to different file sizes: I changed cmake to use g++ - but that did not change filesize. So I suppose, cmake-build is still missing some action, that qmake does. Any idea, how I could find out, what is missing?

Inspect the actual compile and link lines, they may (even probably) differ.

django.Reinhard

@kshegunov said in migration to cmake results in corrupt binaries:

Actually for what it's worth qmake is simpler and I like it more (also because I'm more used to it).

Absolutely!

qmake is like riding a tricycle and cmake is a formula 1 rocket. Every kid mounts a tricycle and races - but you need several licenses to ride a formula 1 rocket.

If qmake could handle dependencies, I had no need to change. Well and custom commands are not well supported. Both build systems don't really support creating helpfiles. In cmake it was easier to embed a custom command in dependencies so that it builds automatically.

@kshegunov said in migration to cmake results in corrupt binaries:

Does that help:

Not really.

I already have that commands in my cmake files. But QtCreator does not show the sources in project tree (to start QLinguist).
And when I start QtCreator->external command->linguist->refresh translations I get the error message, that no ts-files are defined.
But they are - in subprojects.
... any way - I tried to define the ts-files in toplevel cmake file, but it made no difference.

So - its stupid, but actually the only way for me: I use the qmake-project to handle translations and the cmake file for application build.

kshegunov

This thread is really getting off topic, but as long as you are happy with it, it's fine by me.

@django-Reinhard said in migration to cmake results in corrupt binaries:

If qmake could handle dependencies, I had no need to change.

I assure you, it does. If it didn't one wouldn't be able to build Qt itself with it. Something is wrong with the way you've setup your subdir project and that's the reason. Try to run in verbose mode qmake -d to see what's getting parsed/processed.

Well and custom commands are not well supported. Both build systems don't really support creating helpfiles. In cmake it was easier to embed a custom command in dependencies so that it builds automatically.

Actually, it should be rather straightforward. Just the other day I stumbled on one custom command invocation in Qt itself. Here, take a look:
https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/QtBuild.cmake?h=wip/cmake#n3887

I already have that commands in my cmake files. But QtCreator does not show the sources in project tree (to start QLinguist).

Ah, you mean in Creator. That's no fault of the build system, but rather the IDE's integration. There may be some way, but personally, I have no idea.

django.Reinhard

@kshegunov said in migration to cmake results in corrupt binaries:

If qmake could handle dependencies, I had no need to change.

I assure you, it does. If it didn't one wouldn't be able to build Qt itself with it.

Well, not really.
I wasn't aware, that qt is built by qmake too.
But when I look at pro-files from qt, there's much additional coding. So much, that it does not look like a pro-file.
So - its possible to achieve a correct build with qmake - but only if you spent lot of time in additional programming the build system.

I already spent much more time with build-system than I wanted to.

@kshegunov said in migration to cmake results in corrupt binaries:

Just the other day I stumbled on one custom command invocation in Qt itself.

... but that's cmake. No problem there.
I was talking about qmake. But as I saw the pro-files of qt - well, I underestimated qmake obviously.

... anyway - today I finally had the breakthrough I was looking for, so I'm happy with the level I've reached now. But that's a story for a new thread :)

kshegunov

@django-Reinhard said in migration to cmake results in corrupt binaries:

So - its possible to achieve a correct build with qmake - but only if you spent lot of time in additional programming the build system.

I was talking about qmake. But as I saw the pro-files of qt - well, I underestimated qmake obviously.

qmake is old, it may even predate cmake, so yeah, Qt can be/used to be built with it. There was a special bootstrapping (actually I believe it's still in existence) done to build qmake first, before running it over the actual Qt tree. It is a great pain point and people still did it anyway. The support for qmake was dropped not because it's bad or can't do what you want, but because no one wants to pay for the maintenance. Maintaining code is expensive, and when there are de-facto standard tools that's much better from a the developer/company point of view.
Qt's cmake files are no less complicated than the qmake project files, because there's a lot of pre, post and mid build tools that must be run so you can have a smooth experience as a user developer.

But yeah, you must know the tools to wield them effectively. Blanket statements that this or that doesn't work are ... well, unproductive, for lack of a less offensive word. Of course you have to code the build system, code is code, and no build system is going to magically do what you want it to do, especially in some edge case ... so, sorry if I'm not convinced that not knowing the build system well enough should give you confidence to make bold statements that it can't do things or doesn't work.

django.Reinhard

Hi,

@kshegunov said in migration to cmake results in corrupt binaries:

Qt's cmake files are no less complicated than the qmake project files, because there's a lot of pre, post and mid build tools that must be run so you can have a smooth experience as a user developer.

Agree completely.
... and I guess it will stil take a while until using cmake will be that comfortable as qmake was/is.

@kshegunov said in migration to cmake results in corrupt binaries:

I'm not convinced that not knowing the build system well enough should give you confidence to make bold statements that it can't do things or doesn't work.

I do not want to be misunderstood - the bold statements were not bold to increase their truth content, but so that it is also read by people who only skim texts and then write answers that do not fit the question at all.

If that came across wrong, then I'm sorry.
I enjoyed the exchange with you (personally) very much