Hello, author of the PVXS on Meson PR here.
> I'm currently considering how to unify building an IOC [1] and one of
> its dependencies [2], which uses Meson. I am struggling somewhat to
> come up with a proper directory structure and rules to make that
> happen
I think one of the most common way to handle this is by using a
packager manager (in the very loose sense of the word). If your meson
dependency defines a pkg-config file and you install that dependency
using your "pkg manager", then in your IOC you should be able to set:
USR_CFLAGS += `pkg-config --cflags your-dependency`
USR_LDFLAGS += `pkg-config --libs your-dependency`
I do mean "package manager" very loosely here. Some labs use Docker for
that purposes, my lab is using Nix, some uses Debian / RPM packaging,
and others have custom-made package management systems.
> it occurred to me that this would be much simpler if IOCs were built
> with Meson instead of Make.
I think it depends on your current situation. I thinks trying to use
Meson to build traditional IOCs (with .db, .dbd files) would make it
more complicated, just because Meson doesn't allow you to export
functions (actually a feature that I like). Lots of complicated Make
rules are currently implemented just to handle / expand / concatenate
.db / .dbd files, and are needed in both epics-base, and in IOCs.
This is why I've limited the scope of the Meson PR to just PVXS, since
with PVXS you can build IOC using "just" C++.
For such IOCs, I think that yes, integrating external libraries (and QA
tools, documentation tools, packaging) would be easier using Meson.
> There is a PR to PVXS to enable building it with Meson instead of the
> EPICS build system [3]. It depends on a change to epics-base that
> hasn't been merged yet, and I don't know what its status in PVXS is.
> Is it simply waiting for the changes to epics-base, or are there
> outstanding issues and/or objections to the proposal?
To my knowledge, there is currently no reported issues with the
proposals, probably just the core team having more pressing priorities.
The PVXS PR does need the epics-base PR to be merged beforehand.
I think it also comes down to community interest. It still is a build
system that needs to be maintained *in parallel* to the Make build
system, in order to maintain backward compatibility. Contributors will
have to remember to add each new file to both build systems, make sure
the way they make their contribution work with both build systems work,
etc.
I also think that's why limiting Meson to PVXS, a relatively recent
project, is a good thing™.
So, if you want to help moving things along, well you're already doing
it by showing interest, thanks!
You can also gently ping maintainers, if you're feeling the PRs got
forgotten.
> Were that to be merged, would a possible future direction be to
> support a Meson-based template for IOCs (and possibly modules)? It
> might help simplify a lot of workflows and decrease the burden of
> debugging the build system, since meson allows customization in a
> more standardized way.
That's definitely a future that I'd like to see. In my opinion, it
would make it easier to integrate IOCs in these areas:
- packaging & deployment
- CI
- QA tooling (e.g. clang-tidy)
- documentation tools (e.g. doxygen / breathe)
- IDEs
and would ease the EPICS learning curve for people already familiar
with C/C++ development.
Thanks again for showing interest!
--
Rémi NICOLE <remi.nicole at cea.fr>
CEA/DRF/IRFU/DIS/LDISC
- References:
- Using alternative build systems (meson) for IOCs/modules Érico Nogueira Rolim via Tech-talk
- Navigate by Date:
- Prev:
Re: Simple CAN bus over ethernet interface Götz Pfeiffer via Tech-talk
- Next:
how to build base with symbols for Arm? Siddons, David via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
<2024>
2025
- Navigate by Thread:
- Prev:
Using alternative build systems (meson) for IOCs/modules Érico Nogueira Rolim via Tech-talk
- Next:
Simple CAN bus over ethernet interface Evans, Richard K. (GRC-H000) via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
<2024>
2025
|