Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Building handy tools and applications #881
Following on from #808, #812, and #813 it is indeed very handy to have a source for tools that are outside the scope of mxe. As an example, I've always turned a blind eye to
Some sort of sibling or downstream project (mxe-exe?) could be more liberal in what packages it accepts, and would allow the core mxe to be stricter about focussing on libs and headers. We could also possibly use it as place to gather build recipes and examples.
Technical issue: how to use MXE from mxe-exe? I like the idea of Makefile and xxx.mk per package. Can it be used in mxe-exe without copy-paste from MXE? Ideally, it should work transparently as if mxe-exe's packages are MXE packages. Dependencies should work. For example, building qbittorrent in mxe-exe should cause building qt in MXE.
Another proposal. Add "plugins" for MXE. It would work as follows: a user sets MXE variable
PS. #813 has two libs (lzma and ucl) and one executable (upx), which can be considered as a part of a compiler chain. Many people apply it after stripping a binary to make it even smaller.
PS 2. I have one more candidate package keepassx: 6c561c5
Agreed, apps is a pretty universal term these days and it conveys the idea well.
Indeed, but I'd like to convey the idea that these aren't particularly supported. Maybe having them in a separate place will actually cause more work (issue tracker, repo, etc.) but it's hard to say.
It's the old library vs framework debate - does one include MXE from their code and execute it, or does MXE include your code and execute it? I was mostly thinking of the former with some sort of git submodule approach to keep things synced, however ...
I really like this idea, I do something similar in my
Maybe something like an