Limo Build Error: Fatal error: dll.hpp: No such file or directory

[Heisenborgar]

Hello, I'm trying to build Limo so I can do a PR regarding #42. But I encountered this issue when building on my Arch Linux setup. Here are the steps that I did:

1. Clone this repo.
2. Installed dependencies based on my distro: qt5, jsoncpp, libarchive, pugixml, openssl, cpr, libroot, catch2, doxygen.
3. Executed these commands: mkdir tests/build - No error cmake -DCMAKE_BUILD_TYPE=Release -S tests -B tests/build - No error cmake --build tests/build - Errors:

[ 34%] Building CXX object CMakeFiles/tests.dir/home/patrick/Projects/Limo/limo/src/core/installer.cpp.o /home/patrick/Projects/Limo/limo/src/core/installer.cpp:10:10: fatal error: dll.hpp: No such file or directory 10 | #include | ^~~~~ compilation terminated. make[2]: [CMakeFiles/tests.dir/build.make:230: CMakeFiles/tests.dir/home/patrick/Projects/Limo/limo/src/core/installer.cpp.o] Error 1 make[1]: [CMakeFiles/Makefile2:83: CMakeFiles/tests.dir/all] Error 2 make: *** [Makefile:91: all] Error 2

Here's the whole process: Pastebin

[OdinVex]

See what I did with the AUR version of Limo (maintainer). It's the way Limo was set up for compilation, rather wonky. Limo's got a lot of issues around assumption and polishing is also desperately needed. But that "default to ~/Downloads" WILL be removed from the AUR version if it makes it into Limo's code. That is NOT what the ~/Downloads folder is for. No need to pollute it, use XDG standards.

Edit: AUR package name limo-git, see the bit about unrar in the PKGBUILD.

[limo-app]

As @OdinVex mentioned, the current CMAKE file is pretty bad. To be honest, this is my first open source project and i did not anticipate that people would add it to other package managers, which is why the non-flatpak part of the current file is mostly just tailored to my setup, which is obviously not ideal.

Limo's got a lot of issues around assumption and polishing is also desperately needed

This is very likely due to my lack of experience. I hope this will all improve over time and would be grateful for advice, should something particularly bad stick out to you.

[OdinVex]

As @OdinVex mentioned, the current CMAKE file is pretty bad. To be honest, this is my first open source project and i did not anticipate that people would add it to other package managers, which is why the non-flatpak part of the current file is mostly just tailored to my setup, which is obviously not ideal.

Limo's got a lot of issues around assumption and polishing is also desperately needed

This is very likely due to my lack of experience. I hope this will all improve over time and would be grateful for advice, should something particularly bad stick out to you.

I didn't mind putting the AUR one together, it's all good. I'd recommend checking into Qt API (you use a lot of sfs namespacing even though QFile is included and is...right there? to use for reading/writing, etc). It's also not obvious where Limo.conf was. Plus the source format and variable naming such as varname is...not need by me before. ^_^; Edit: Politely meant, it looks like you might come from a completely different programming language background and maybe that's what is tripping me up a little but I'm an anti-rust old schooler that still prefers C/C++/Assembler. I found this most helpful for Qt projects:

cppcheck --check-level=exhaustive --enable=all --library=qt ./*.*pp

[limo-app]

you use a lot of sfs namespacing even though QFile is included and is...right there

I realize this must seem really strange and using the Qt implementation would probably be better at this point. A bit of background: When i began writing Limo, i didn't know which GUI framework to use. To not entirely box myself into Qt from the beginning, i decided to strictly separate GUI classes from non-GUI classes by not using any Qt functionality when not absolutely necessary. This led to a situation where everything in src/core can be compiled without Qt, while the class ApplicationManager acts as a sort of interface to Qt code. I am currently unsure if i should keep this separation.

Plus the source format and variable naming such as varname is...not need by me before

When starting out, i looked for a style guide to follow and found several references to the Google one. This is where some of the oddities, like the trailing underscore for class members, originate. If this an odd choice, i would be happy to change my style to something more commonly used for C++. Do you have a suggestion?

I found this most helpful for Qt projects:

Thank you! I will go over the warnings this produces.

[OdinVex]

"not need by me before" I typoed, I meant not "seen" by me before, but I was multitasking with someone in my ear. ^_^ My bad. As for style, I'd say first decide what framework you'd like to use. Qt is cross-platform and runs great. If you're wanting the whole "themed" app bit, a lot of people use Electron (I despise it myself, but I'd not let that stop anyone from using it of course). If you want to keep the UI separate from the functionality I'd suggest making the functionality a standalone library and simply using a Qt UI project that references it, single project (that has two sub-projects in it).

For C/C++ I'm partial myself to Bjarne Stroustrup's style but with slight differences (usually considered negligible such as newline or not for curly-brackets and such). Qt slightly alters it simply because of parsing (required for compilation).