Re: [Mingw-cross-env-list] MXE packages as APT

[Volker Grabsch]

Dear Boris,

This is really great work!

Regarding your last question, it would be interesting to hear more
opinions from others on that.


Nagaev Boris schrieb:
> 3. The tool was renamed to build-pkg.lua and is ready to be merged into MXE 
> [2].

Pull request merged.

However, I noticed the following strange comment at the beginning
of tools/build-pkg.lua:

-- mxedeb, Build DEB packages from MXE packages
-- Instructions: http://mxe.redjohn.tk

This seems to refer to the old package name.  (Since this is just a
comment, I merged the pull request nevertheless.)


> 5. While running the tool, location of MXE directory MUST be
> /usr/lib/mxe (same as the directory where it is installed to).
> Otherwise paths in many files are broken (e.g., in mxe-conf.cmake).

It seems that this is neither documented nor checked anywhere.

Is it possible to perform a very simple check at the beginning
of the script?

For example, just complain if /usr/lib/mxe doesn't seem to be
an MXE directory.  (Or, maybe you find some better criterion.)

> 7. Size of packages is rather big. Installing Qt and Boost requires
> downloading 600 Mb. Shall we strip binary files? Packages' sizes would
> decrease by times.

I agree with the sentiment to keep package sizes small.  We already
try to reduce sizes by not building (and installing) documentation.

However, this is always a secondary goal, while the primary goal is
"feature completeness" in the sense that when trouble starts, all you
need is there.  This is especially important for Debian packages.

That's why I don't think we should strip library files such as .a or
.dll files.  So our MXE packages are more like the lib-*-dev Debian
packages and no so much like the simple lib-* packages.

On the other hand, I believe that stripping additional stuff such as
.exe files should be fine.  These are meant to be copied to the target
system anyway (or to be run via Wine).  In other words, these things
aren't part of the compiling/debugging efforts.

Any other opinions?

What should we strip?  How far should we go to keep package sizes small?


Regards,
Volker

-- 
Volker Grabsch
---<<(())>>---