Skip to content
  • 0 Votes
    3 Posts
    408 Views
    P

    Hello! Updating from my side.
    Thank you @SGaist for your answer, for future people facing the same issue: I did not have any uncommon character in the paths more than underscores.

    My fix:
    I figured with some help and testing deploying to other folder structures that qmake was the problem and complaining.
    Placing the whole project one level up (C:\Repos\NewLevel\ ...) fixed the issue and no problem from Qt whatsoever.

    It is purely a workaround that Qt seems to be ok with. As my version control begins after NewLevel, it is also not an issue. Maybe I will try in the future to take it down one level after some update in Qt, but AFAIK it is not a reported bug.
    As I said, other machines with identical Project Strcture using same Qt Version and QtCreator seemed to be okay with that. The Makefiles look also the same in terms of relative paths.

  • 0 Votes
    5 Posts
    508 Views
    KH-219DesignK

    @johnco3 said in porting qmake pro file to mac - library issue:

    how I should use or handle the environment variables that point to the homebrew directories?

    I have a sample project (my own "living cheatsheet") that compiles a Qt GUI for mac (and other platforms). You don't have to take my word for it, you can look at the Github "Actions" (continuous integration) to see that the builds are succeeding.

    My "cheatsheet" project:

    uses homebrew: https://github.com/219-design/qt-qml-project-template-with-ci/blob/master/tools/ci/provision_mac.sh#L10 makes minor use of macx blocks in pro/pri files

    For my baseline project, the only macx blocks I seem to need are the following "quality of life improvements":

    ios|macx { # the lines below suppress warnings generated by Qt's header files: we tell # Clang to treat Qt's (mac) Framework headers as "system headers": QMAKE_CXXFLAGS += -iframework $$[QT_INSTALL_LIBS] QMAKE_CXXFLAGS += -isystem $$[QT_INSTALL_LIBS]/QtCore.framework/Headers }

    and

    ios|macx { # Disable a couple that are more onerous to comply with on Mac QMAKE_CXXFLAGS += "\ -Wno-error=missing-noreturn \ -Wno-error=sign-conversion \ " }

    (in the file https://github.com/219-design/qt-qml-project-template-with-ci/blob/master/compiler_flags.pri)

    However, the baseline project does not link to anything from homebrew.

    On another project (not public on github), here are some other snippets I have used:

    macx { # MacOSX homebrew puts the mysql.h header elsewhere: QMAKE_CXXFLAGS += -isystem /usr/local/include/mysql } macx { LIBS += -L/usr/local/lib -lmysqlclient }

    Once your code compiles, you will very likely find yourself face-to-face with another common MacOS hurdle: the app bundle. Reference: https://developer.apple.com/go/?id=bundle-structure

    In order to make a bundle that will launch (so you can actually launch your app), the Qt "magic" you will need is macdeployqt:

    https://github.com/219-design/qt-qml-project-template-with-ci/blob/master/build_app.sh#L91

  • 0 Votes
    12 Posts
    710 Views
    N

    Thank you all ! It worked !!!!!

    Yes the solution was TEMPLATE = lib !

  • 0 Votes
    4 Posts
    956 Views
    Y

    @Bonnie
    .pro file is identify the path but the issue is, whenever I do rebuild at that time it is not call to linuxdeploy.sh.

    I want to know if any variable is call the to script on build.

  • 0 Votes
    1 Posts
    1k Views
    No one has replied
  • 0 Votes
    3 Posts
    1k Views
    onurAO

    @jsulm
    I need it for the rcc command. Whenever I run rcc in terminal, the binary output is re-generated, although the .qrc is the same.

    Is there a way to check it in qmake for example? Like a flag?
    Thanks in advance!

  • 0 Votes
    4 Posts
    2k Views
    L

    Thank you for the hint about 'solved'.

  • 0 Votes
    12 Posts
    10k Views
    SGaistS

    Just thought of something: you are trying to cross-compile a linux kernel on OS X. You should rather create a virtual machine using e.g. VirtualBox and do everything directly form Linux. That will save you time.

  • 0 Votes
    4 Posts
    2k Views
    K

    @ankit-thakar said:

    @koahnig
    Thanks for looking into problem
    I got your point. and as you said i had also the same doubt that it was causing due to parallel execution of jom. as a part of solution i thought i need to change in .pro file in such a way that jom can interpret correctly,
    Is this ok to implement?
    I do not know, since I am not using msvc anymore. My experience is with msvc 2005 and Qt libs, but that is outdated for sure (and also hard to remember)

    And one more thing also i found is that When i start debugging using nmake.exe it takes around 10 minutes to just do one step into process and when i am using jom.exe for debugging it takes only 30 sec / 1 min.
    i don't know what is the story behind this....(may be jom performs parallel execution that's why)

    I do not think that this is directly related. jom is basically a substitute for nmake. The only influence is can imagine is that nmake/jom is started prior to the debugging process. What could have happened is that nmake had to compile your whole project. However, 10 minutes is a pretty long time and requires a larger project I would expect. Anyway you will see in the compilation output, when all is compiled. You can compare then to the procedure with jom. The start of debugging itself should be independent of jom and nmake afterwards. I do not know that there could be an influence of multi-threading on the debugging process. But again I am not using msvc compiler.

  • 0 Votes
    5 Posts
    5k Views
    S

    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!

  • 0 Votes
    4 Posts
    2k Views
    M

    Hi and welcome to devnet,

    your project uses Qt to build so you need it.
    In your case I suggest to move to CMake (but still you need to install it on the build machines)