When building with Qt Creator, you have to disable the QtQuick compiler in the qmake build step. Simply unchecking the checkbox and rebuilding solved the problem.

@koahnig
Thanks so much

When i add this line:

typedef EGLSurface (EGLAPIENTRYP PFNEGLCREATEPLATFORMWINDOWSURFACEEXTPROC) (EGLDisplay dpy, EGLConfig config, void *native_window, const EGLint *attrib_list);

after all include in file src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmwindow.cpp compile was finished great.

Hi and welcome to devnet,

That's a question you should rather bring to the interest mailing list. You'll find there Qt's developers/maintainers. This forum is more user oriented.

Hi and welcome to devnet,

Qt Creator should auto detect the compiler for you. However what usually happens is that people install Visual Studio without checking the C++ option during installation thus they have a VS environment but nothing to build C++ code.

You should first check that.

Note that you also need to install the debugger separately. The one coming with VS is "internal" and cannot be used by other applications.

I did install the one coming with the Qt package, there is no other version installed.

@koahnig said:

Either you need to add "-j4" as make parameter to each of your projects. Otherwise you can set also "MAKEFLAGS=-j4" to your environment (e.g. for a kit as suggested above).

Correction to above post. I have set it to system environment. I did not get it to work in kit environment. Both were set due to my trials, but the latter alone (in kit environment) does not help.

That's a good news but still a strange mystery…

By the way, no need to modify the thread title, you can mark it as solved using the "Topic Tool" button :)

That one's a classic (and a question that regularly comes back)

Fine, Thanks.

@jitu059_Lalat The long and short if it are, you have two ways to do this:

Find all the dll's that your app depends on. You can do this with the tool http://www.dependencywalker.com/. Once you found all the dll's copy them into the same folder as your executable. This is now your "delivery package" you will copy the executable + dlls from PC to PC. This method is perhaps a bit easier/faster in the short term, but when you compile with different versions of Qt/Windows you may require a different set of dlls (i.e. Qt4 Dlls don't match Qt5 Dlls).

Download the Qt source code and compile it for static linking. Then when you build your code you will get a much larger executable file, but it will contain everything it needs - a standalone executable. This is perhaps a bit more work on your part, but master this and it makes deploying your project from PC to PC much easier.

Have a go at one or other method, if you get stuck then ask again. But as SGaist said, there is lots of documentation out there already : )

You did a complete rebuild as well?
The run of qmake does not create an error code, but it does not introduce a moc statement into makefile.
I guess you are using a shadow for compiling. Delete the whole shadow folder, rerun qmake once again and rebuild.

If you think it imay be a bug related to Qt 5.5 you can check on JIRA.

Use the latest version of the SDK(At this time 24.3.3), Use Ant(Gradle still won't work), Use the latest NDK and latest Qt Creator Release.(5.4 at this time). That's what I did to get it to work for me. Large thanks to sk2212 and all the other idea's!

Then what distribution are you running ? Which Desktop Manager ?

Okey I finally soved it bu adding this line to the CMakeList
INCLUDE_DIRECTORIES("/usr/include/qt4/")

I don't know why the authors didn't put this line into the CmakeList.

I finally made it, thanks to your link. I was indeed using the wrong library. I also missed the libxcb plugin but I added it to the project "package" and it now works fine. I was ready to bang my head against the walls.

qmake provides functions for processing the contents of variables during the configuration process.

As QMAKE_FILE_NAME is a run-time and not a configuration-time variable it cannot be edited by clean_path, seems this problem cannot be solved this way, anyone any ideas?

EDIT:

I think I finally found a proper solution:

PROTOS = interface_definitions.proto PROTOPATH = $$relative_path($$PWD, $$OUT_PWD) \

protoc is now being called this way:

protoc --cpp_out=. --proto_path=. --proto_path=../project/ ../project/interface_definitions.proto

everything works fine now!

Hi,

For the interface part, you could have a common library that offers all the interfaces (e.g. MyAbstractPluginInterface) that your plugin will use and link to that library.

Hope it helps

@sierdzio said:

Thanks a lot for the clarification.

@Chris-Kawa,

Thank you very much for guiding me , it is very useful to me

@grafzahl said:

I also now use the system command.

If you can, I suggest to use QProcess to run external commands. This for two reasons:

QProcess is cross-platform (in the future you could want to build your application also on other platforms); You can have direct access to the standard out/err, ....