Re: [Mingw-cross-env-list] MXE as virtual environment (python needs to run itself natively during installation)

[Volker Grabsch]

Václav Šmilauer schrieb:
> >While this is an entirely valid approach, it is not the
> >way we usually go in MXE. We're using Wine for testing,
> >but not as part of the build system.
> >
> >However, if this is the only way you get it work, by all
> >means you should go that route.
>
> I think I will try the compilation in virtual environment as the
> first step. I would attempt proper cross-compilation afterwards -- I
> guess patching python and getting those patches upstream would be
> beyond my capacity (mostly time-wise) at this moment.

Detecting and reporting cross-compiling related issues, in case
there are any, would also be a great help in itself.

Also note that we don't expect anyone to actively lobbying
for their patches to be accepted by upstream. It's all about
offering, using upstream's respective issue tracker or mailing
list.

Extra points for reading their criticism (unless they accept
the patch as is), and for providing better patches. But as
always, that is a question of time and motivation.

> 1. If you use wine for testing, is there some infrastructure ready,
> like pre-generating wine configuration and such? Would you mind
> enabling wiki at github, so that I could make notes there, which
> would be eventually a mini-howto to do such a thing?

No, there isn't any such "infrastructure". The normal testing
happens completely without Wine. There are small test programs
and it's all about being able to compile and, more importantly,
to link them successfully. Running them is _not_ part of the
usual test cycle.

Of course that doesn't ensure they're actually working. But
especially in cross-compiling, those simple tests are very
effective: We already know that the libraries are working via
native build, so we don't test the library themselves but
the cross-build system. It's mostly about fixing linker flags,
including all dependency libraries, and fixing pkg-config scripts,
CMake variables, and so on.

The generated test programs are running *.EXE files, and sometimes
we also run them via Wine. However, that's usually done by hand
and only if we suspect there's an issue. As far as I remember, no
special Wine configuration is needed for that. Just install e.g.
the standard Debian packages for Wine, and everything should work.

> 2. I would like to install MSYS (form what I understood, that is
> what I need for bash, make and other tools probably necessary to
> compile other stuff). I might first try binary installation (if that
> works),  though I would like to do source installation first. Is it
> ok to add a Makefile for it into src/ ?

I don't understand what you're trying to do, and I'm afraid you are
confusing MSYS with MXE. All I can say is that MXE currently doesn't
run on MSYS, although I know some people have been working on that.
We're happy to accept compatibility patches for MXE so it runs under
MSYS with fewer issues. But don't actively encourage this. MXE is
mainly designed to run on Unix systems such as Linux or BSD systems.

> 3. I recall reading somewhere about windows installer being created
> with MXE, and it seems the project using MXE use that. Can I get
> some pointers here?

MXE has direct support for NSIS. Some people are also using
InnoSetup. Please have a look at:

https://github.com/mxe/mxe/issues/71

> I tried downloading toppler source, but see
> nothing relevant there... (I would put that on the wiki again)

In the source tarball "toppler-1.1.3.tar.gz", please have a
look at "toppler.nsi.in", from which the configure script will
generate "toppler.nsi". The latter file is used to generate the
installer via NSIS, using the "makensis" command. See target
"dist-win32" in "Makefile.am".

> 4. Boost is currently compiled --without-python. SHould I aim at
> providing a special boost-python makefile, or would it be OK to make
> boost depend on python headers? (Python base installation is
> relatively small and the compilation takes a minute).

Since we aim to be feature complete, it would be great if you
just make the boost.mk work with python. The dependency
"boost -> python" should be perfectly fine.


HTH, and again, thanks for your work!


Regards,
Volker

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