Add Meson build system

[tintou]

This is the first iteration to add the Meson build system

[hfiguiere]

+1 on principle.

[tintou]

If anyone want to give it a try 🙂 I'm unsure if there are some C flags that are still missing

[msmeissn]

@ndim fyi

[ndim]

@msmeissn I know that meson exists, and that is the extent of my knowledge about it.

[hfiguiere]

My take is simple. I take meson over antyhing else for a new project build system. I take meson over CMake to migrate away from autotools.

• meson is well supported on the "major" platforms, the trifecta of Linux, macOS and Windows, and supports BSD
• meson is way less obscure than autotools (I know both)
• with ninja as a build runner, it's way faster, and parallel by default

[axxel]

I for one certainly like the idea to replace autotools and if @hfiguiere says '+1' instead of 'HELL NO', then maybe meson has a chance ;). I was very interested in Meson when Yussi released it (there might even be some version generation related code from me still floating around in the code base ;)), but it was not fulfilling my requirements at the time, so I chose cmake back then. Bottom line: I'm not familiar with how it works nowerdays.

That said: maybe @tintou can comment on the question of whether or not meson could be of help with my cross-compilation question: #1032?

Also, since starting the build setup from scratch is obviously the right time to raise the subject: can we do away with having libgphoto2_port as a separate library? And while at it: from an "embedded" developers perspective, it would be preferable to have the option to build a statically linked library with statically linked port and camera drivers (usb + ptp2).

[dfandrich]

I not against moving to meson (although I've yet to be convinced the alleged advantages make it worthwhile) but I am against having two build systems at the same time (except for a short period during migration). When I've seen that happen in the past, the two very quickly go out of sync making builds inconsistent and creating subtle bugs. Developers also then need to learn two systems instead of one, reducing the pool of people able to fully contribute. If the powers that be decide on meson, automake should be deleted.

[tintou]

I for one certainly like the idea to replace autotools and if @hfiguiere says '+1' instead of 'HELL NO', then maybe meson has a chance ;). I was very interested in Meson when Yussi released it (there might even be some version generation related code from me still floating around in the code base ;)), but it was not fulfilling my requirements at the time, so I chose cmake back then. Bottom line: I'm not familiar with how it works nowerdays.

That said: maybe @tintou can comment on the question of whether or not meson could be of help with my cross-compilation question: #1032?

Meson has a very extensive Cross compilation manual, the main difference with Autotools is that everything has to be explicitly set.

Also, since starting the build setup from scratch is obviously the right time to raise the subject: can we do away with having libgphoto2_port as a separate library? And while at it: from an "embedded" developers perspective, it would be preferable to have the option to build a statically linked library with statically linked port and camera drivers (usb + ptp2).

The port I'm showing here is trying to be as close as a 1:1 port from autotools so I'm not doing any change regarding libgphoto2_port being separate, that can be changed afterwards. Using them as a static library is nevertheless possible with the -Ddefault_library=static option at configuration time.