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
We just got support for multiple --cross-files flags in https://github.com/mesonbuild/meson/pull/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 https://github.com/mesonbuild/meson/issues/3972 with the use-case of GCC's "multilib" in mind.
CC @rossburton
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.
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.
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"
thanks
On Thu, 21 Mar 2019, 00:56 John Ericson, notifications@github.com 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
https://github.com/mesonbuild/meson/issues/5125#issuecomment-475082397,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYPsTFnFGq_t00aXQyLe1QtNoV4bqbszks5vYtjKgaJpZM4b_yS2
.
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.
Most helpful comment
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.