Build multiple cross binaries

[nicola-lunghi]

Hi,
I have a java project that needs the following directory structure

resources
├── Linux
│   ├── armv5
│   │   └── libHello.so
│   ├── armv6
│   │   └── libHello.so
│   ├── armv6-hf
│   │   └── libHello.so
│   ├── armv7
│   │   └── libHello.so
│   ├── armv7-hf
│   │   └── libHello.so
│   ├── armv8_32
│   │   └── libHello.so
│   ├── armv8_64
│   │   └── libHello.so
│   ├── x86
│   │   └── libHello.so
│   └── x86_64
│   └── libHello.so
├── OSX
│   ├── x86
│   │   └── libHello.jnilib
│   └── x86_64
│   └── libHello.jnilib
└── Windows
├── x86
│   └── Hello.dll
└── x86_64
└── Hello.dll

where currently each file is build using a Makefile and passing different compilers and flags

what could be the best way to create this structure in meson and run all the cross builds?
Thanks

[Ericson2314]

We just got support for multiple --cross-files flags in #5083, a very nice cleanup. But at the same time I want to also pass multiple --cross-files, creating multiple host machines rather than overridding each other, for exactly this sort of thing. I first brought this up in #3972 with the use-case of GCC's "multilib" in mind.

CC @rossburton

[jpakkane]

Do you need to build every platform .so file in one go? That is not supported in Meson and is unlikely to because it complicates things a lot. If building one at a time is fine, then you can detect which platform you are building for and only recurse in that directory.

If you need all at once the only feasible option is to have a build driver that builds all the different setups in their own build dirs and then combines the results.

[Ericson2314]

I think we can do it without crazy complexity a few refactors from now, but yeah let's not rush/force it. Wrapper script is definitely the way to go in the short term.

[nicola-lunghi]

Do you need to build every platform .so file in one go? That is not supported in Meson and is unlikely to because it complicates things a lot. If building one at a time is fine, then you can detect which platform you are building for and only recurse in that directory.

Its not my fault unfortunately seems that all the jars are build in a manner similar to this "by hand".
The idea is that I have 1 source code and multiple output binaries that needs to be rebuilded if the source changes.

This is an idea of a similar Makefile

https://github.com/java-native-access/jna/blob/master/native/Makefile

or another one

https://github.com/Fazecast/jSerialComm/blob/master/src/main/c/Posix/Makefile

but is a mess and only works in the developer workstation.

I was searching a tool that permit to write something "nicer"

[nicola-lunghi]

thanks

…

On Thu, 21 Mar 2019, 00:56 John Ericson, ***@***.***> wrote: I think we can do it without crazy complexity a few refactors from now, but yeah let's not rush/force it. Wrapper script is definitely the way to go in the short term. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5125 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYPsTFnFGq_t00aXQyLe1QtNoV4bqbszks5vYtjKgaJpZM4b_yS2> .

[jszakmeister]

I've run into several projects where this kind of support would be useful. In one case, there needs to be parts built for 32-bit and 64-bit processes and both need to be present. In other cases, there is more than one CPU of different architectures and they both work in conjunction with each other (you need both think of one as being the supervisor and the other as being the workhorse). In both cases it's not the same software built for two platforms, it's one platform that has multi-architecture things going on.