[Bug 679115] Windows: Make the GStreamer DLLs/data relocatable

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=679115
  GStreamer | gstreamer (core) | git

Fan, Chun-wei <fanc999> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #218883|0                           |1
        is obsolete|                            |

--- Comment #5 from Fan, Chun-wei <fanc999 at yahoo.com.tw> 2014-01-08 10:00:39 UTC ---
Created an attachment (id=265680)
 View: https://bugzilla.gnome.org/attachment.cgi?id=265680
 Review: https://bugzilla.gnome.org/review?bug=679115&attachment=265680

Make The GStreamer Installation Relocatable on Windows (take iii)

Hi,

Sorry it took much longer than I liked to come back to this issue, but here's
my other take on this, hopefully addressing the issues that have been brought
up. :)

(In reply to comment #4)
> ::: gst/gst.c
> @@ +124,3 @@
> +{
> +  return g_build_filename (
> +    g_win32_get_package_installation_directory_of_module
> (_priv_gst_dll_handle),
> 
> Leaks return value of g_win32_get...()

I think it's fixed in this patch of mine.

> @@ +125,3 @@
> +  return g_build_filename (
> +    g_win32_get_package_installation_directory_of_module
> (_priv_gst_dll_handle),
> +    "lib",
> 
> If it is called lib or not depends on the parameters passed to configure, i.e.
> --libdir. Could also be called anything else

I think this is the general convention that is used on Windows for the GTK+, so
following suit here:)  This also applies to MSVC builds, which do not use
configure to build.

> @@ +1129,2 @@
>    g_type_class_unref (g_type_class_peek (gst_allocator_flags_get_type ()));
> 
> 
> Why these unrelated changes? :)

Oops, this patch does not have this anymore :)

> ::: gst/gstpluginloader.c
> @@ +65,3 @@
> +{
> +  return g_build_filename (
> +    g_win32_get_package_installation_directory_of_module
> (_priv_gst_dll_handle),
> 
> Leaking return value

Fixed in the latest version of my patch.

> @@ +67,3 @@
> +    g_win32_get_package_installation_directory_of_module
> (_priv_gst_dll_handle),
> +#ifdef _DEBUG
> +    "debug",
> 
> Is this standard?

Nope, but I am following suit from the pre-generated config.h in win32/common. 
We could always purge this part, if needed. :)

> @@ +69,3 @@
> +    "debug",
> +#endif
> +    "lib",
> 
> This one is in libexec, not lib. Also configurable with --libexecdir at
> configure

Putting it here as "lib", as it is a helper.  Please advise if libexec is
preferred to be set as something else. (perhaps with the other .exe's?)

> @@ +73,3 @@
> +    NULL);
> +}
> +#define GST_PLUGIN_SCANNER_INSTALLED get_plugin_scanner_dir()
> 
> You'll leak the memory here because the code below assumes it's a static string

Fixed in the latest version of my patch.

> ::: gst/gstpreset.c
> @@ +110,3 @@
> +{
> +  return g_build_filename (
> +    g_win32_get_package_installation_directory_of_module
> (_priv_gst_dll_handle),
> 
> Leaking return value

Fixed in the latest version of my patch.

> @@ +118,3 @@
> +#undef GST_DATADIR
> +#endif
> +#define GST_DATADIR get_datadir()
> 
> Leaking the memory below

Fixed in the latest version of my patch.

> ::: gst/gstregistry.c
> @@ +142,3 @@
> +{
> +  return g_build_filename (
> +    g_win32_get_package_installation_directory_of_module
> (_priv_gst_dll_handle),
> 
> Leaking return value

Fixed in the latest version of my patch.

> @@ +144,3 @@
> +    g_win32_get_package_installation_directory_of_module
> (_priv_gst_dll_handle),
> +#ifdef _DEBUG
> +    "debug",
> 
> Is this standard?

Same as the "debug" thing above.  Let me know if this is preferred without :).
> @@ +1609,3 @@
>      /* add the main (installed) library path */
> +    GST_DEBUG ("scanning main plugins %s", plugin_dir);
> +    changed |= gst_registry_scan_path_internal (&context, plugin_dir);
> 
> There is already code like this in gstregistry.c, 5 lines below :)

Noticed that, so moving a block down:)

With blessings, thank you!

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.