4 ms·
> a giant pita It's not hard at all. You can add them to some directory with your app, or they can be behind some url, or you can mail them physically in a US
by Nokinside 6y ago
> a giant pita
It's not hard at all. You can add them to some directory with your app, or they can be behind some url, or you can mail them physically in a USB stick to anyone who requests them by mail or phone.
You just have to be able to provide them if somebody wants them. In reality nobody ever wants them. It's just some directory with gpl-stuff/ you add to your software.
How hard it is to have some binaries lying around?
- vlovich123 6y agoThe complexity comes into getting that machinery going in your build system and hosting. Additional complexities arise very quickly once you start optimizing your build (cmake object targets, LTO). I’m not saying it’s infeasible. Just saying that usually it’s easier to ship the Qt DLL and be done with it. From my observation of the space I’ve not seen anyone really ship the “here’s the object file” approach (it had happened before I’m sure but it’s not the norm for a reason).
- Reelin 6y agoJust do your linking in a final build step that 1: Only reads in object files and resources (ie rejects source code); 2: Bundles up all the object files into an archive; 3: Outputs the final executable alongside the archive. You mentioned LTO. Don't the LLVM and GCC LTO implementations currently involve outputting compiler IR to object files, then running the optimization passes against the full collection of object files prior to linking? So they inherently collect all the object files together in a linkable form. (Of course, it's probably more efficient to just dynamically link Qt and pay for a license if you want to publish for iOS.)