Fix: Avoid symbol export when building statically with MSVC

[leonardo7901]

🛠️ Fix: Avoid unnecessary symbol export with static MSVC builds

Summary

This patch ensures that __declspec(dllexport) is not applied when Aravis is built statically with MSVC. It updates the logic in meson.build to conditionally apply the ARV_API macro only for shared builds, improving compatibility and cleanliness of static builds on Windows.

---

🔍 Problem

When building Aravis statically with MSVC (e.g., via vcpkg with x64-windows-static triplet), the current build system still applies __declspec(dllexport) globally. This leads to:

• Generation of .lib and .exp files next to user executables.
• Unnecessary export symbols in static libraries.
• Confusion in build setups expecting pure static linking behavior.

This behavior is not aligned with standard MSVC conventions, where symbol export macros are only needed in shared (DLL) builds.

---

✅ Solution

This patch modifies the logic in meson.build:

if cc.get_id() == 'msvc'
  if build_shared
    cc_export_define = '__declspec(dllexport) extern'
  else
    cc_export_define = 'extern'  # static build: no export
  endif
elif cc.has_argument('-fvisibility=hidden')
  if build_shared
    add_project_arguments('-fvisibility=hidden', language: 'c')
    cc_export_define = 'extern __attribute__ ((visibility ("default")))'
  else
    cc_export_define = 'extern'
  endif
else
  cc_export_define = 'extern'
endif

Now, when default_library is 'static', no __declspec(dllexport) is added — restoring correct static build behavior.

Also, this patch explicitly adds:

default_options: ['default_library=shared']

to the project() declaration in meson.build. This ensures that unless otherwise specified, builds will default to shared libraries, preserving existing workflows and expectations.

Users who want static builds can still explicitly override this with:

meson setup builddir --default-library=static

---

💡 Justification

This change:

• Respects standard MSVC static linking conventions.
• Avoids unintended .exp/.lib files when building user executables.
• Improves compatibility with tools like vcpkg and Visual Studio.
• Has no impact on non-MSVC or shared builds.
• Does not alter the existing ARV_API macro or ABI.

---

🧠 Historical Context

This aligns with an earlier discussion in PR #550 (2021), where initial MSVC support was proposed. Back then:

• ARV_API was added to manage symbol visibility.
• The concern was raised about leaking symbols from static libraries.
• Author noted that ARV_API should be conditional and not clutter headers unnecessarily.
• This patch implements that feedback in a non-invasive, backwards-compatible way.

---

🧪 Testing

Confirmed working with:

• Visual Studio 2022
• MSVC toolchain (x64, /MTd)
• Aravis built via vcpkg with x64-windows-static
• No .exp/.lib artifacts appear at app link time.
• Verified behavior is unchanged for shared builds.

---

🔗 Related

• PR #550
• MSVC symbol export guidelines (MSDN)

[Copilot]

Pull Request Overview

This PR fixes MSVC symbol export behavior when building Aravis statically by ensuring __declspec(dllexport) is only applied for shared builds, not static ones.

• Adds conditional logic to only apply ARV_API export macros for shared MSVC builds
• Sets default library type to shared to preserve existing build behavior
• Improves GCC visibility handling consistency

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}