You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I love SCons for the reproducible experiments, but I think it is a mess for the installation process. I'd like to suggest using Meson builder.
I'm always frustated when I want to install Madagascar on an OS that is not whithin the range of supported ones, like Arch linux, or NixOS. Since have to often use it on servers, it is a pain to set up every time. It lacks portability of installation, which hurts its most fundamental principal of being a seismic processing suite for making reproducible experiments. However, if the person running my experiment doesn't have madagascar installed, what's the point? I kinda lose face when I think about putting my source code on my papers knowing the editors most likely will not be able to run everything.
Meson has a built-in plataform dependency check tool, unit testing, and a much, muuuch simpler sintax. On top of it, it has crazy fast compilation times, because it uses the ninja builder as a backend. Additionally, it has support for several languages (fortran, python, c++, c, java, rust...)
Using Meson would undoubtedly make the installation process more portable, bringing along a buch of neat features.
Describe the solution you'd like
I'd like to implement the installation part of madagascar entirely on meson. This includes all of the user contributed binaries too, leaving only the api as a separate repository all together.
I already have a simple fork with only the api here. I think this is the right approach, since a lot of people just want the i/o part of madagascar to make their programs, since resources on remote servers are limited. That way, you can just import the api as a meson subproject, grab the dependencies and compile and run your code.
The api would be included as a subproject for the full installation, which would compile everything using it. After the installation, SCons would continue to be used as a reproducible experiments recipe laguange.
Describe alternatives you've considered
I considered simply making a PR adding meson builder support without removing support for SCons. However, the way the project is laid out is not good, first I'd like to make fundamental changes to the way we organize files. I also considered CMake, but it would be too much of a mess to implement and it doesn't support all of the languages Madagascar supports. Continuing to use SCons is also one alternative, but not one I'd like to persue.
Additional context
This is a problem that rubs me the wrong way for a long time now. I don't feel like porting my codes using madagascar to the official repository mainly because I completely disagree with the way it works with regards to the development part, although the user part is very good.
Meson would help packaging Madagascar to various operating systems. With the layout I'm proposing, most people will just make their projects using the api, and the official repo just has to wrap then as a subproject. The development would become much much easier to maintain. Please take that into consideration when I make my PR.
Thanks for your time!
The text was updated successfully, but these errors were encountered:
@AtilaSaraiva, thanks for your suggestion to Madagascar project. You should assign the main developers of this project to this issue, such as @sfomel and @zhichenggeng.
Yeah, I think so too. I'm a bit occupied this week, but I intend to work on this fork soon, then make a PR when I have a solid result. The challenge gonna be to write meson build instructions for all the madagascar binaries, but first I need to prototype the folder structure. After everything is working we need to think of a way to help researchers transition to the meson build system from SCons. I was also thinking about some terminal interface python program in which the developer could specify the name of the project, the main source file, the dependencies (openmp, opencl, mpi...) and the languages of the source files, and a sample meson.build file would be written with the madagascar api wrapper in the subprojects folder.
It would be even more awesome if madagascar was included in the nix package manager after the transition to meson was complete, allowing people in any linux distro to install it without a hassle, and even get automatic updates.
🎉 Feature request
Is your feature request related to a problem? Please describe.
I love SCons for the reproducible experiments, but I think it is a mess for the installation process. I'd like to suggest using Meson builder.
I'm always frustated when I want to install Madagascar on an OS that is not whithin the range of supported ones, like Arch linux, or NixOS. Since have to often use it on servers, it is a pain to set up every time. It lacks portability of installation, which hurts its most fundamental principal of being a seismic processing suite for making reproducible experiments. However, if the person running my experiment doesn't have madagascar installed, what's the point? I kinda lose face when I think about putting my source code on my papers knowing the editors most likely will not be able to run everything.
Meson has a built-in plataform dependency check tool, unit testing, and a much, muuuch simpler sintax. On top of it, it has crazy fast compilation times, because it uses the ninja builder as a backend. Additionally, it has support for several languages (fortran, python, c++, c, java, rust...)
Using Meson would undoubtedly make the installation process more portable, bringing along a buch of neat features.
Describe the solution you'd like
I'd like to implement the installation part of madagascar entirely on meson. This includes all of the user contributed binaries too, leaving only the api as a separate repository all together.
I already have a simple fork with only the api here. I think this is the right approach, since a lot of people just want the i/o part of madagascar to make their programs, since resources on remote servers are limited. That way, you can just import the api as a meson subproject, grab the dependencies and compile and run your code.
The api would be included as a subproject for the full installation, which would compile everything using it. After the installation, SCons would continue to be used as a reproducible experiments recipe laguange.
Describe alternatives you've considered
I considered simply making a PR adding meson builder support without removing support for SCons. However, the way the project is laid out is not good, first I'd like to make fundamental changes to the way we organize files. I also considered CMake, but it would be too much of a mess to implement and it doesn't support all of the languages Madagascar supports. Continuing to use SCons is also one alternative, but not one I'd like to persue.
Additional context
This is a problem that rubs me the wrong way for a long time now. I don't feel like porting my codes using madagascar to the official repository mainly because I completely disagree with the way it works with regards to the development part, although the user part is very good.
Meson would help packaging Madagascar to various operating systems. With the layout I'm proposing, most people will just make their projects using the api, and the official repo just has to wrap then as a subproject. The development would become much much easier to maintain. Please take that into consideration when I make my PR.
Thanks for your time!
The text was updated successfully, but these errors were encountered: