[PATCH] Handle mingw in main Makefile

[Bertrand Jacquin]

Hi,

I had a need to be able to install luajit for mingw as I do for a
standard linux host, so I needed to able to run 'make install' in the
top directory for any or both destination arch, this for packaging
purpose.

I saw that the top directory Makefile is not able to handle MinGW target
as stated on http://luajit.org/install.html :

Configuring LuaJIT

The standard configuration should work fine for most installations.
Usually there is no need to tweak the settings. The following files hold
all user-configurable settings:
src/luaconf.h sets some configuration variables.
Makefile has settings for installing LuaJIT (POSIX only).
src/Makefile has settings for compiling LuaJIT under POSIX, MinGW or
Cygwin.
(..)

So I did a quick and dirty to top directory Makefile to handle this, so
all is controlled using TARGET_SYS variable as it's done in
src/Makefile. The patch is attached, and is not meant to be used as-is,
but just to get an answer from you if that's the way you see things for
future.

So some questions :
- Why have all the "smart stuff" in /src/Makefile and not in /Makefile
? To be able to just run 'make' in src/ dir ?
- Are you interesting in a more generic way to have install work for
other platform as MinGW ? so we can easily make dist packages.

Thanks,
Bertrand

[Mike Pall]

Post by Bertrand Jacquin
So I did a quick and dirty to top directory Makefile to handle this,
so all is controlled using TARGET_SYS variable as it's done in
src/Makefile. The patch is attached, and is not meant to be used
as-is, but just to get an answer from you if that's the way you see
things for future.

Well, TARGET_SYS is not set in the top-level Makefile and I don't
think it's a good idea to replicate the logic there.

Anyway, I wonder what's the point in installing a MinGW-compiled
LuaJIT binary and the associated Lua libraries in the POSIX
locations? The package.[c]path configuration is set up for the
(completely different) Windows-centric locations, which are
relative to wherever you wish to install the binary.

Post by Bertrand Jacquin
- Why have all the "smart stuff" in /src/Makefile and not in
/Makefile ? To be able to just run 'make' in src/ dir ?

Yes. And because plain Lua does it this way, too.

Post by Bertrand Jacquin
- Are you interesting in a more generic way to have install work
for other platform as MinGW ? so we can easily make dist packages.

I'm not sure what you mean?

--Mike

[Daniel Kolesa]

Post by Mike Pall

Post by Bertrand Jacquin
So I did a quick and dirty to top directory Makefile to handle this,
so all is controlled using TARGET_SYS variable as it's done in
src/Makefile. The patch is attached, and is not meant to be used
as-is, but just to get an answer from you if that's the way you see
things for future.

Well, TARGET_SYS is not set in the top-level Makefile and I don't
think it's a good idea to replicate the logic there.
Anyway, I wonder what's the point in installing a MinGW-compiled
LuaJIT binary and the associated Lua libraries in the POSIX
locations? The package.[c]path configuration is set up for the
(completely different) Windows-centric locations, which are
relative to wherever you wish to install the binary.

It might be useful for MinGW crosscompiler on POSIX systems that has its
own prefix with Windows libraries and includes.

Post by Mike Pall

Post by Bertrand Jacquin
- Why have all the "smart stuff" in /src/Makefile and not in
/Makefile ? To be able to just run 'make' in src/ dir ?

Yes. And because plain Lua does it this way, too.

Post by Bertrand Jacquin
- Are you interesting in a more generic way to have install work
for other platform as MinGW ? so we can easily make dist packages.

I'm not sure what you mean?
--Mike

Daniel

[Bertrand Jacquin]

Hi,

Post by Mike Pall

Post by Bertrand Jacquin
So I did a quick and dirty to top directory Makefile to handle this,
so all is controlled using TARGET_SYS variable as it's done in
src/Makefile. The patch is attached, and is not meant to be used
as-is, but just to get an answer from you if that's the way you see
things for future.

Well, TARGET_SYS is not set in the top-level Makefile and I don't
think it's a good idea to replicate the logic there.
Anyway, I wonder what's the point in installing a MinGW-compiled
LuaJIT binary and the associated Lua libraries in the POSIX
locations?

This is needed when your cross-toolchain is located in a dedicated
SYSROOT, and then this SYSROOT is used to build software based on that
SYSROOT.

Having a working 'make install' for such case make easier lot of stuff
that are needed to be done manually for the moment.

Post by Mike Pall
The package.[c]path configuration is set up for the
(completely different) Windows-centric locations, which are
relative to wherever you wish to install the binary.

Post by Bertrand Jacquin
- Why have all the "smart stuff" in /src/Makefile and not in
/Makefile ? To be able to just run 'make' in src/ dir ?

Yes. And because plain Lua does it this way, too.

Post by Bertrand Jacquin
- Are you interesting in a more generic way to have install work
for other platform as MinGW ? so we can easily make dist packages.

I'm not sure what you mean?

I mean a less hacky hacky Makefile than that I provided.

[Mike Pall]

Post by Bertrand Jacquin

Post by Mike Pall
Anyway, I wonder what's the point in installing a MinGW-compiled
LuaJIT binary and the associated Lua libraries in the POSIX
locations?

This is needed when your cross-toolchain is located in a dedicated
SYSROOT, and then this SYSROOT is used to build software based on
that SYSROOT.

Umm, I think you're missing the real issue at hand:

A MinGW-generated luajit.exe *requires* the lua51.dll and the
jit.* modules to be placed in Windows-centric, relative locations,
because that's how it's configured.

These locations do *not* match the (POSIX) 'make install'
locations. You can't even run the installed luajit.exe, if it's
installed in the POSIX directories, because it won't find the
lua51.dll! And it doesn't make any sense to package up the
resulting mess, because it won't run anywhere.

The concept of a SYSROOT only makes sense for a POSIX build. But
the MinGW build is not a POSIX build.

It doesn't matter whether you build with MinGW natively on Windows
or cross-compile it from a Linux host with a cross-MinGW toolchain.
The target environment is always Windows, not POSIX.

--Mike