What is the usual way of generating Export headers?

[mscofield0]

What is the usual way of generating Export headers? And making sure that the export header turns to dllimport for targets using a library and dllexport when it's being built on its own?

I keep getting linker errors when using a shared library and trying to use the library in my tests. I see there's gnu_symbol_visibility, but that doesn't work on Windows. And also I don't know how I would toggle it on and off automatically if a different target in the project is using it.

Another question, less relevant to the above, is it discouraged to create custom run targets to configure and build targets (probably, since the note on the docs says that it shouldn't be used for building) but I don't see a prettier way of automating and isolating the different targets. I want the app target to be configured differently than test, and I want to keep them separated from one another.

[mscofield0]

To get a better understanding of what I'm doing, or at least trying to do, here's the project.

I've recently added options to separate the targets, but that's annoying and I'll probably change it...

[eli-schwartz]

GNU symbol visibility on GCC-like compilers is purely optional. The project will build either way, and support building either static or shared and linking into other libraries or executables... but using symbol visibility allows to keep a clean symbol table and well-kept ABI, and also allows the compiler to do better optimizations and inlining.

My understanding is that on MSVC you need to either build multiple copies of every object (one for static linking and one for shared) and use a project-specific c_args define to switch a custom header if/else that defines a macro expanding to the declspec you currently want to build for...

OR you can use a vs_module_defs file e.g. myproject.def and meson will generate the correct link flag /DEF:myproject.def (which only applies to shared libraries) and then you don't need declspec attributes.

As for "to configure and build targets", I'm not sure what you mean there. I think maybe what you mean is that you want a run_target where you first set up a builddir, and then run ninja create-profile1 which in turn runs meson again but with the setup options you want?

I recommend instead you add a machine file for each profile. meson setup --native-file profiles/app.ini and that native-file will contain an options section that specifies the configure-time options you want to use.