Re: [Meson-devel] Use of sub directories
Brought to you by:
jussip
From: Jussi P. <jpa...@gm...> - 2014-01-19 21:57:25
|
On Sun, Jan 19, 2014 at 10:23 PM, Lars Pensjö <lar...@gm...> wrote: I got it working for my (medium complex) project now > (see Ephenation client<https://github.com/larspensjo/ephenation-client/blob/mesonbuild/Source/meson.build> > ). > I have several sub folders with source code, but so far I have only one > main meson.build. > Cool. That is the largest third party Meson project I have seen thus far. > The list of source code files is rather long, and it would be nice to > specify a separate list for each sub directory. I am not sure how to best > do that. I can use the subdir() command to access a local meson.build in > each sub directory. That works, but there are some minor inconveniences: > A common convention is that the source in one subdirectory should provide one unit (be it a library, executable, or something else). I do understand that as projects get bigger, this becomes harder and harder. However if you wish to have source from multiple subdirectories in one target, one simple way to do it is something like this: adir_src = ['a/one.cpp', 'a/two.cpp'] bdir_src = ['b/three.cpp', 'b/three.cpp) executable('myexe', sources : ['main.cpp', adir_src, bdir_src]) You can create arrays of (arrays of) strings and Meson will automatically flatten them for you. I might add something that works like include_directories, that is, it remembers the path to sources and you can then pass these around. I need to think a bit how that is best implemented. The obvious follow up question to this is "Couldn't I just glob the source files?". The answer to this is, unfortunately, no. One of Meson's main design goals is that it must be fast and scalable. The reason Ninja works so fast is that it knows exactly which files to inspect. If a build target is defined in terms of a globbing operation, then it would need to traverse the full contents of the source tree (or parts thereof) on every invocation. There is no way to make that fast. > > An alternative solution is to use subproject() and static libraries. But > these sub projects will not get access to states defined by the main > project, which is a problem to me as they are really part of the same > project. > You don't need subprojects for static libraries. Subproject is designed for one very specific goal. Suppose you have a third party library libfoo (that builds with Meson) that you want to use. On Linux you would use pkg-config but on Windows you can't. On Windows you would put the full upstream release source in a subdirectory and call subproject(). Then you could grab the output targets (usually static/shared libraries) and use them as if they were a part of your own project. But you should only need to use it on third party libraries, not your own code. If you want to build your subdirectories as static libraries, you can totally do that with subdir(). So something like this. In subdir a: stat_a = static_library('stata', 'foo.cpp', 'bar.cpp') In subdir b: stat_b = static_library('statb', 'baz.cpp', 'bof.cpp') and then in your toplevel dir you would do: executable('myexe', 'main.cpp', link_with : [stat_a, stat_b]) Just be aware that because of the way static linking works, if you have a circular dependency between stat_a and stat_b you will be in a world of pain. |