I've looked this presentation now. Looks pretty neat.

Unfortunately now we don't support any buildsystems, so marking it as enhancement.

One thing I was curious about from the talk had to do with dependency checking. It sounded like the dependency for re-linking tests was based on the symbol list of the shared library. What wasn't obvious to me is if this list contained enough information to gather if a function's ABI changed. Is that the case? (autotools goes through quite a bit of work to make that happen).

Either way, we have *a lot* of existing code with automake that we have to support. We also have a group of people that really want to use Builder outside the context of GNOME (from init systems to web apps). That means that we need an abstraction a layer above build systems. And to make it even harder, we need that all in C (or C++, or a very strict subset of Vala).

What would be useful is if we could build that abstraction in lockstep with your Meson work so that we are sure we encapsulate as many use cases as possible.

Another thing I'd like to see from Meson (selfishly) is a grammer we can use to build parsers using yacc. In particular, most things "look" like function calls in a python'ish domain specific language. I'd actually love something that used more of a symbol in a grammer for things like settings, dependencies, libraries, etc. I think that would result in something very nice.

> What wasn't obvious to me is if this list contained
> enough information to gather if a function's ABI changed.
> Is that the case?

The reality is a bit more complicated than I had time to go into but the basic gist of it is this:

An executable that uses a symbol from a shared library depends on two things: the library file and the header file (obtained via gcc's automatic dependency printer). If either the list of symbols is changed the relinking happens and if the symbol meaning changes (such as changing the amount of arguments to a C function) then the program is both recompiled and relinked because the header has changed.

> What would be useful is if we could build that abstraction in lockstep
> with your Meson work so that we are sure we encapsulate as many use
> cases as possible.

Yes, this seems like a smart thing to do. Are you coming to FOSDEM? I'm not sure yet but if yes it might make sense to have a quick chat over this.

> Another thing I'd like to see from Meson (selfishly) is a grammer we can use > to build parsers using yacc. In particular, most things "look" like
> function calls in a python'ish domain specific language. I'd actually
> love something that used more of a symbol in a grammer for things
> like settings, dependencies, libraries, etc. I think that would
> result in something very nice.

One of the goals of Meson is to provide all introspection and configuration operations via command line tools exactly so that IDE developers don't need to write parsers for it. Currently the main missing thing is creating and removing targets (and files in them). If you have something else in mind then please write down a simple example of what and how you want things to be done.

(In reply to comment #3)
> Yes, this seems like a smart thing to do. Are you coming to FOSDEM? I'm not
> sure yet but if yes it might make sense to have a quick chat over this.

Yeah, I'll be at the GNOME hackfest in Cambridge and then in Brussels the 30th-1st.

> One of the goals of Meson is to provide all introspection and configuration
> operations via command line tools exactly so that IDE developers don't need to
> write parsers for it. Currently the main missing thing is creating and removing
> targets (and files in them). If you have something else in mind then please
> write down a simple example of what and how you want things to be done.

The idea that is in my head at the moment is a tree like structure that is populated by build system backends. Then clients (in this case the IDE) can watch for events on the tree. I also want to bundle a set of "logical operations" that perform transforms on the tree.

(In reply to comment #3)

[...]

> > What wasn't obvious to me is if this list contained
> > enough information to gather if a function's ABI changed.
> > Is that the case?
> 
> The reality is a bit more complicated than I had time to go into but the basic
> gist of it is this:
> 
> An executable that uses a symbol from a shared library depends on two things:
> the library file and the header file (obtained via gcc's automatic dependency
> printer). If either the list of symbols is changed the relinking happens and if
> the symbol meaning changes (such as changing the amount of arguments to a C
> function) then the program is both recompiled and relinked because the header
> has changed.

Sorry if I am missing something obvious, but how do you detect that the symbol meaning changed?  I mean, how do you detect that, for instance, a type "struct foo" passed in parameter to the function "func" gained a new data member.  Do you parse the header file for that, or do you analyse the binary of the library itself, like what libabigail (https://sourceware.org/libabigail) does?

> Yeah, I'll be at the GNOME hackfest in Cambridge and then in
> Brussels the 30th-1st.

I just booked my travel to Fosdem, so let's meet there.

> Sorry if I am missing something obvious, but how do you detect that the
> symbol meaning changed?  I mean, how do you detect that, for instance,
> a type "struct foo" passed in parameter to the function "func" gained 
> a new data member.  Do you parse the header file for that, or do you
> analyse the binary of the library itself, like what libabigail 
> (https://sourceware.org/libabigail) does?

The change detection is the same as what regular C compiles do: whenever a header changes all files that include said header are recompiled. This is perhaps best explained with an example.

Suppose we have a shared library S, whose struct is defined in header H. In addition we have executable source E that links with S.

When the source is compiled the first time, Meson tells GCC to print dependency info for all files and imports that, so now we know that E depends on H.

If we change H in any way (whether it changes API or not), both S and E are rebuilt.

If we change the implementation of S without touching the headers, S is rebuilt but E is not relinked.

This scheme has false positives (recompilations when not strictly needed) but no false negatives (recompilations skipped when they are necessary). Thus it is reliable but does not always lead to optimal performance.

Created attachment 336233 [details]
Meson plugin dir

A Meson build plugin skeleton. Unzip it in the plugins dir (does not contain anythin else so if any wiring needs to happen for it to work, then that needs to be added).

Not tested because I don't have recent enough of a setup at the moment. For the same reason some parts are not implemented, but there is step by step documentation how it should work so someone with knowledge of Builder internals should be able to hook it up pretty quickly.

Thanks for starting on this!

I already started working on one, it is located in this branch: https://git.gnome.org/browse/gnome-builder/log/?h=wip/tingping/meson

It is a bit more work than Christian set it out to be but it builds and runs so far. Will continue smoothing out the internal API and I'll probably report a few additions from Meson. For example we expect the install directory but `mesonintrospect` doesn't expose that. Looking at the Meson source this is actually determined by the build backend though (unless custom).

Install dir is not defined by the backend, only the values of prefix et al. We should expose it introspect data, but apparently currently don't.

This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.