libretro / blastem

Upstream tracking repo of BlastEm, the fast and accurate Genesis emulator, with libretro specific changes
https://www.retrodev.com/blastem/
GNU General Public License v3.0
54 stars 25 forks source link

Switch on meson building system #34

Open vit1251 opened 3 years ago

vit1251 commented 3 years ago

Meson may detect library location and invoke pkg-config and mutch more. How about porting make on meson? I can start if someone support this initiative.

kivutar commented 3 years ago

Hi, we try to link as less system libs as possible in libretro builds. So most of the dependencies are most of the time removed or vendored. What lib is not detected in your case?

vit1251 commented 3 years ago

I meet with issue #33 and want to contribute to building scenario. I am well-known meson and know that most project replace autotools and make scripts.

meson may help to organize components (vendoring) or detect system library.

Also meson may generate Visual Studio, make, cmake, ninja and other build scripts bases on existing toolsets on system.

But you right meson is Python application and require Python 3 and as I understend ninja building system.

If you interesting that direction I can revrite Makefile on meson for exmaple in Pull request.

kivutar commented 3 years ago

Right now, upstream is using a Makefile, and 90% of libretro cores are using a static Makefile, so I doubt switching to meson would be a good idea.

It would slow down the inclusion in some embedded distro that would have to package mesen to be able to build blastem from source.

The buildbot would also need to be updated to support mesen. Too much work IMO.

eli-schwartz commented 3 years ago

Hi, we try to link as less system libs as possible in libretro builds. So most of the dependencies are most of the time removed or vendored.

For what it's worth, meson makes it very easy to vendor dependencies. In fact, you can vendor dependencies without even stopping other people from using the system ones. e.g. if you would like to vendor zlib, add this file to subprojects/zlib.wrap:

# https://wrapdb.mesonbuild.com/v2/zlib_1.2.11-5/zlib.wrap
[wrap-file]
directory = zlib-1.2.11
source_url = http://zlib.net/fossils/zlib-1.2.11.tar.gz
source_filename = zlib-1.2.11.tar.gz
source_hash = c3e5e9fdd5004dcb542feda5ee4f0ff0744628baf8ed2dd5d66f8ca1197cb1a1
patch_url = https://wrapdb.mesonbuild.com/v2/zlib_1.2.11-5/get_patch
patch_filename = zlib-1.2.11-5-wrap.zip
patch_hash = 728c8e24acbc2e6682fbd950fec39e2fc77528af361adb87259f8a8511434004

[provide]
zlib = zlib_dep

meson then does not use pkg-config to look for it, but downloads and builds a private, static copy. (This is controlled by the user via the build system option --wrap-mode={default|nofallback|forcefallback}.)

Also there is a basic (but improving and under active development) C11 implementation of meson called muon so I do not believe python is a dealbreaker (but it's not like python is hard to get).

keithbowes commented 2 years ago

I'd really like to see RetroArch itself ported to Meson. The ad-hoc configure file is lacking. Though, I'm not sure about porting individual cores to use Meson; the standalone make files for the individual cores seem fine, as there's not too much customization you need to do, other than maybe setting CC, CXX, and platform variables. Maybe if Meson can handle some platform differences, that would simplify things considerably (most of the make files deal with setting platform-specific variables), but I don't think that's a strong point of Meson.

Python is widely used by RetroArch/libretro already, so yes, I don't see it being a big deal. In fact, that's why I wrote the script to convert Nestopia's NstDatabase.xml file into a header file in Python. My first instinct was to use a shell script, but I thought Python would be much more portable, especially since it's used by RetroArch already.

eli-schwartz commented 2 years ago

I think Meson does pretty well at handling platform differences?