Subproject install on windows

[Jeff Wright]

So I've got a project on Windows with multiple subprojects. The problem is that the built subproject DLLs are not available to the top level project binary. I'm not sure how to get them to install/copy to the top-level project's build location. 

I have the libraries set to install : true. Is there some way to set the install location to be a location relative to the top level project's build tree?

Just to be explicit, the build tree looks like this now:

debug

    ├───meson-logs

    ├───meson-private

    ├───subprojects

    │   ├───btree

    │   ├───freetype

    │   │   └───src

    │   │       ├───freetype@sha

    │   │       │   └───subprojects

    │   │       │       └───freetype

    │   │       │           └───src

    │   │       └───freetype@sta

    │   ├───glfw

    │   │   └───src

    │   │       ├───glfw@sha

    │   │       │   └───subprojects

    │   │       │       └───glfw

    │   │       │           └───src

    │   │       └───glfw@sta

    │   ├───glm

    │   ├───stb

    │   ├───vma

    │   └───vulkan

    └───VulkanApp@exe

The output for the subprojects is in the "src" directories. 

[Jussi Pakkanen]

On Thu, Feb 1, 2018 at 3:12 AM, Jeff Wright <jeff...@gmail.com> wrote:


> I have the libraries set to install : true. Is there some way to set the
> install location to be a location relative to the top level project's build
> tree?

The short answer is to not do that. Having multiple copies of a dll in
the same build tree is very fragile and can break in various
interesting ways.

The longer answer is that it is possible to make executables run from
the build tree (just like on unix with rpath) using manifest files. We
would really like to add support for those so all of this shuffling
goes away (we already fake it during unit tests by manipulating PATH).
The downside is that none of us really knows how to actually implement
this and we have been fairly busy with other things. If there are
people with the relevant Windows experience, please submit patches for
this. Thanks.

There are two simple workarounds for this issue. The first is to do an
install to some throwaway directory (so that all exes and dlls are in
the same dir) and run your program from there. The second is to use
static linking.

[Jeff Wright]

Okay, installing to a temporary directory is fine by me for now. As a follow-up, is it possible to install as part of the build process (i.e. just by running ninja once?) Right now I have all my targets set as install : true, but they only install if I explicitly call "ninja install" after calling "ninja" to build.

[Jussi Pakkanen]

On Thu, Feb 1, 2018 at 6:04 AM, Jeff Wright <jeff...@gmail.com> wrote:
> Okay, installing to a temporary directory is fine by me for now. As a
> follow-up, is it possible to install as part of the build process (i.e. just
> by running ninja once?) Right now I have all my targets set as install :
> true, but they only install if I explicitly call "ninja install" after
> calling "ninja" to build.

That is by design. Most projects and platforms do development in the
build dir and they do install only rarely. Thus running install on
every build would be slow and on some setups would require root
privileges.

[Jeff Wright]

I've just found the --layout option for when you call meson to create a build tree. Setting that to flat seems to also accomplish what I need for now. 

One note, it would be nice to see the layout selected when you call "meson configure" in a build directory. Right now it's not visible there, but it seems you can call "meson configure -Dlayout=flat" in a build directory and it does work.