General build/deploy guidance for Pi and general open source release

[Linwood]

I am fairly new to the unix/open source world, and would appreciate some advice.

I have a Qt application that is intended for the Pi (or similar device). I develop and test on a distro version of Qt/Qtcreator on a VM Ubuntu, and then move the source to my Pi (3B), change the .pro file slightly for paths (changing x86_64-linux-gnu to arm-linux-gnueabihf), run qmake/make to compile on the Pi from distro versions there, and it all works.

I did it this way because it was relatively simple, since there were matching distro versions on both platforms.

But in reading I see lots of advice about not moving projects between platforms, instead to cross compile. Which might (or might not) fix my path issue above.

And maybe I can fix the path issue with some of the substitutable macros, have not tried hard. I do see that the testable values like "win32" and "unix" do not seem to include flavor conditionals like arm vs x86_64.

So my real question is: if I plan to open source this, is there a general philosophy of how it gets built for the Pi that is more... normal? That may be less problematic for others to sue?

Or am I even asking the right question -- maybe I should be changing my project so it ought to work regardless, and need to be exploring those path issues and not assuming cross compiling would magically fix it?

(At present the project, suitably edited, compiles fine on either platform but I have made no effort to build a cross compile environment)?

Is there a good "For those about to offer an open source QT project" checklist somewhere - basically a "how to make life easier for someone who might want to use this but may be in a completely different environment?"

[anda_skoa]

For relatively weak devices it is more custom to cross-compile from a workstation, also because the target device might not have a build chain installed.

I am, however, puzzled that you had to change any paths, or that you have system paths in your .pro file at all.

Cheers,
_

[Linwood]

Your question sent me off trying to figure that out, thank you.

When I first added poppler (the qt5 bindings) I tried to use qtcreator to locate them, and I used Add Library, and External Library to locate them as that seemed most applicable. That works, but it adds a ton of conditionals and an explicit path to the library itself which included /usr/lib/x86_64-linux-gnu/.

Seeing the conditionals made me think I was supposed to find one matching the Pi and change it there, but after your question I dug a bit more and realized I should find the library with the native OS (just list it in LIBS by name) and for the include I could either put it in the INCLUDEPATH or start with the top level and do #include "poppler/qt5/poppler-qt5.h". I'm not sure which is most correct, but neither of them appear to cause errors in porting to the other platform.

So I no longer have a path I need to change in the project file, works nicely. Thanks for the shove.

Part of the reason for the original question was a sense from some postings (here's one (http://stackoverflow.com/questions/4495637/how-can-i-move-my-qt-project-to-another-pc)) that one shouldn't move project files, but maybe I read to much into that. And if moving a project file is OK, then I really do not think I care whether someone who gets this builds it on the pi, or cross compiles, in which case...

I think the answer to the original question is: It doesn't matter. Right?

[anda_skoa]

I think the answer to the original question is: It doesn't matter. Right?

Right. If building on the target is OK for your speed wise, then there is no problem at all.

Cheers,
_

[Linwood]

Thank you for taking the time to respond to a somewhat misguided question, it helped.