haxeui / hxWidgets

Haxe externs (and wrappers) for wxWidgets
MIT License
77 stars 22 forks source link

Static linking #19

Closed ianharrigan closed 3 years ago

ianharrigan commented 8 years ago

At some point it will be required to actually ship applications created with hxWidgets to other machines that dont contain the wxWidgets framework.

This lib contains the windows dlls (which i think should be removed soon anyway) and they can be shipped with the final .exe. At the moment linux / osx requires to have the wxWidgets lib installed on the system, which isnt ideal.

The first and best option (imo) is to enable static linking. Another is to also allow .dlls (and .so?) files to be shipped with the application. Both these should be options.

I had a quick play on windows and didnt get very far with static linking but opening this as a reminder that its fundamental to the usefulness of this lib.

ibilon commented 8 years ago

On windows having the dll next to the executable should work out of the box I think.

On mac and linux that requires a flag on the link step.

ianharrigan commented 8 years ago

Yeah, agree that on windows having the .dlls is fine, and its what i use. But its not ideal.

I think it should be an option of course, but i also think we should be able to specify that we want to statically link it and end up with a single .exe.

ianharrigan commented 8 years ago

I also wish there was someway to have that clever build macro come into play for windows also, instead of having these huge libs / dlls as part of the repo. That is certainly not ideal.

ianharrigan commented 8 years ago

So this looks pretty easy so far on windows, heres my steps so far:

Havent actually tried to use anything, but build was a no brainer.

TheSHEEEP commented 8 years ago

That does sound like it could be automated, though. Of course, I wouldn't say that is a requirement in any case.

To the static linking: Static linking is something that is only very rarely done at all (outside of mac) because it comes with a heap of practical problems (e.g. having to re-build/upload/download the entire executable whenever something minor changes, and that is only one problem). So I would actually suggest to never do that if not absolutely required. If you really plan on doing that anyway, at the very least make it optional.

Distribution with dynamically loaded libraries is easy on Windows, as you noted. And on linux, it can also be done rather easily* by rpath modifications, which can even be done after something was built using a tool like https://nixos.org/patchelf.html . I always use that when shipping something on 'nix platforms.

ianharrigan commented 8 years ago

Yeah, i believe i have it working for all options: dlls, libs in both /MT and /MD configs - just sanity checking myself

ianharrigan commented 8 years ago

Right, that seems to be working now (for windows)

ianharrigan commented 8 years ago

Right, that seems to be working now (for windows). The default is to use it as a dll. However, you can specify WXSTATIC (-D WXSTATIC) and you will end up with a single .exe and no .dll dependencies