There's quite a lot of libraries using Qt and one of the pitfall is that even if there's Qt in the name it does not make them an official Qt module nor a supported Qt library. However, it is still valid to ask questions about them here as there might be a chance that one, or more, forum members might have experience with it.

If you want to contribute to Qt you should start here: https://wiki.qt.io/Qt_Contribution_Guidelines

@SGaist @aha_1980 Yeah, I thought of "low level" plugins anyway, as I don't want to extend Qt ifself, but a user application with my widget library. @SGaist said in Qt Widget Library vs. Qt Plugin advice: That said, if your goal is to provide a set of widgets for other to use in their application (such as the widgets module), then there's no need for plugins. Ok, I'll try a plain shared library and see how it goes :) Thank you both of you.

clazy is also using libclang

@jsulm @Christian-Ehrlicher Well, my code doesn't work after but I'll figure it out later. I can say that the linking works properly now. Thanks for your help guys!

@starkm42 Thanks for the reply, the issue was to do with the fact mosquitto was compiled with a different library. To avoid this I am just going to run a ubuntu VM Thanks everyone for the help.

@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

@JonB Well not against offering you a beer, or two...(or more :-)) @JonB said in undefined reference - Help first time external header library QT C++ [Linux]: At this point have you considered dropping this third-party Borland stuff completely and using Qt's QTcpSocket to do whatever you want from TCP instead? But I'm not offering to change your own source code over from using Borland TCP to Qt's ;-) This APi is used for GPIO manipulation from an ethernet GPIO modules : [image: b6f5b0bd-e4f1-4708-a16a-d49f89d9dbe8.png] What you say seems really true, cause the documentation about the use with Visual studio c++ do not refer at any moment about any library, only cpp/h files. I will try to use this documentation and use into my *.pro file only the files used into Visual Studio. https://www.deditec.de/media/pdf/manual_e_delib.pdf#page=26&zoom=auto,-329,815 I will made you a feedback of course

@JonB Thanks, I normally use CQTDeployer. That would mean for other projects the DLLs also need to be added under LIBS in the .pro file ?

@SGaist Great Thank you this, I know that qt has its own MQTT module just I had already developed my code for MQTT using the mosquitto library before I knew I was going to be making a GUI using QT.

Yes, I solved it. I don't remember how I installed it but strangely my installation missed ONLY this qhelplink.h and QHelpLink. How strange!

They both seem like dead projects, nothing you can rely on. grassator/react-qml last commit was Dec 15, 2017 only 1 contributor, only active 4 years ago. ongseespace/react-qml last commit was Mar 26, 2020 had 2 contributors, most active 3-4 years ago. As you may sensed for the extremely few amount of responses before and considering that ReactJS is since many many years one the most prominent JavaScript library in the world, mostly top 1 (https://2021.stateofjs.com/en-US/libraries/front-end-frameworks). It looks not to be in the priority of the Qt strategy. Looking at the architecture of Qt, they seem pretty much incompatible. Qt is a complete stack with a complete e2e experience. Where you don't want to mix other stacks or other frameworks. That also means, I think, you cannot for example create QML based components that are reusable in other frontend stacks, where the backend may be anything else. QML are closed components. So, in other words no support for Web Components specification: https://www.webcomponents.org/introduction which was created to be able to produce reusable components. If anybody, disagrees or have more insights, happy to know about it :)

@JonB sweet Jesus on the bike... this is the dumbest typo I ever made. I am so embarrassed atm. Thank you :D

If doStuff() is not const, then don't declare d pointer as const: Q_D(myClass) // NO "const" here! d->doStuff();

Yes @JonB, it requires depencencies but this is not a problem. I will install this automaticly after users choice. You can find them under: LTS RELEASE https://dotnet.microsoft.com/download/dotnet-core/3.1 Current release https://dotnet.microsoft.com/download/dotnet/5.0 Note: .net CORE works with Linux, macOS und Windows.

@jsulm thank you really much - now i can really start to learn/write :D

Are you trying to move things around in the folder where you are currently doing the application deployment ?

@Opa114 Thanks for the feedback. So please mark this topic as SOLVED now.