[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-windows
Subject:    [patch] Re: WITH_PREFIX for kdemodules?
From:       Jarosław Staniek <js () iidea ! pl>
Date:       2007-11-09 0:15:11
Message-ID: 4733A68F.30208 () iidea ! pl
[Download RAW message or body]

Alexander Neundorf said the following, On 2007-11-08 21:51:
> On Thursday 08 November 2007, Allen Winter wrote:
>> On Wednesday 07 November 2007 15:42:28 Alexander Neundorf wrote:
>>> On Monday 05 November 2007, Alexander Neundorf wrote:
>>>> On Monday 05 November 2007, you wrote:
>>> ...
>>>
>>>>> And I agree. We shouldn't be linking to plugins.
>>>> So, does anybody else still have objections against removing
>>>> "WITH_PREFIX" ?
>>> So, conclusion: I'll remove the "WITH_PREFIX" option and no plugins will
>>> have the "lib" prefix anymore, I'll commit next monday.
>> This coming Monday is a bad time.  We are trying to tag a Development
>> Platform. I think this will cause a lot of breakage in the apps, which will
>> cause extra frustration and delays we don't need at this time.
> 
> So how about the monday after that ?
> It only changes the name of the created plugin, and if I understood correctly 
> they are searched in both versions currently, so why do you think it could 
> cause a lot of breakage ?
> 
> Jaroslow, what do you think ?

I'll try to present as simple solution as possible from my POV.

Surprisingly, I'd go with
"1) leave it as it is and keep the "WITH_PREFIX" option, so some plugins have
the "lib" prefix and others don't"

(for now)

why?

1. it's a tagging time

2. I've already cooked a code (the patch is attached; please review) that:

(a) adds a "lib" prefix for an init_ symbol name in case when a symbol without 
  the "lib" prefix is not found ; see part of the patch related to klibrary.cpp

(b) by the way it simplifies some redundant windows lib/plugin loading code 
from kdecore/util/

- -
re linking to modules:

I am unsure whether allowing linking to modules is a big win, when the price 
paid is a bit more obfuscated design for kde dev platform's runtime.

But note, to use symbols from a module that is also used as a lib, we need to 
export symbols. So we should not forget that app_export.h export files have to 
contain another FOOMODULE_EXPORT macro as well.

We need to somehow force cmake to define a kind of MAKE_***_LIB macro for us 
while compiling such special modules to export expected symbols other than its 
entry point. Does it work already?

E.g. note that on windows library binaries go to bin/
(${LIB_INSTALL_DIR} == bin) so binaries of the special modules would go there 
as well, something not very appealing (we want to avoid a need for multiple 
locations for binaries what would force us to modify the $PATH so we install 
.exe's and .dll's in the same place).

The next step would be to use lib prefix _only_ when module is also used as a lib.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice: http://www.kexi.pl/en, http://www.koffice.org
  KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org

["util.patch" (text/plain)]

Index: klibloader.cpp
===================================================================
--- klibloader.cpp	(wersja 731542)
+++ klibloader.cpp	(kopia robocza)
@@ -59,41 +59,33 @@
 
 extern QString makeLibName( const QString &libname );
 
-extern QString findLibraryInternal(const QString &name, const KComponentData &cData);
+extern QString findLibrary(const QString &name, const KComponentData &cData);
 
-//static
-QString KLibLoader::findLibrary(const QString &_name, const KComponentData &cData)
-{
-    QString libname = findLibraryInternal(QDir::fromNativeSeparators(_name), cData);
 #ifdef Q_OS_WIN
-    // we don't have 'lib' prefix on windows -> remove it and try again
-    if( libname.isEmpty() )
+// removes "lib" prefix, if present
+QString fixLibPrefix(const QString& libname)
+{
+    int pos = libname.lastIndexOf( '/' );
+    if ( pos >= 0 )
     {
-      libname = _name;
-      QString file, path;
-
-      int pos = libname.lastIndexOf( '/' );
-      if ( pos >= 0 )
-      {
-        file = libname.mid( pos + 1 );
-        path = libname.left( pos );
-        libname = path + '/' + file.mid( 3 );
-      }
-      else
-      {
-        file = libname;
-        libname = file.mid( 3 );
-      }
-      if( !file.startsWith( "lib" ) )
-          return libname;
-
-      libname = findLibraryInternal(libname, cData);
+        QString file = libname.mid( pos + 1 );
+        QString path = libname.left( pos );
+        if( !file.startsWith( "lib" ) )
+            return libname;
+        return path + '/' + file.mid( 3 );
     }
+    if( !libname.startsWith( "lib" ) )
+        return libname;
+    return libname.mid( 3 );
+}
 #endif
-    return libname;
+
+//static
+QString KLibLoader::findLibrary(const QString &_name, const KComponentData &cData)
+{
+    return ::findLibrary(_name, cData);
 }
 
-
 KLibrary* KLibLoader::library( const QString &_name, QLibrary::LoadHints hint )
 {
     if (_name.isEmpty())
Index: klibrary.cpp
===================================================================
--- klibrary.cpp	(wersja 734474)
+++ klibrary.cpp	(kopia robocza)
@@ -113,6 +113,11 @@
     t_func func = reinterpret_cast<t_func>(lib->resolveFunction( symname ));
     if ( !func )
     {
+#ifdef Q_OS_WIN
+        // a backup for cases when developer has set lib prefix for a plugin name (she should not...)
+        if (!factoryname.startsWith("lib"))
+            return kde3Factory(lib, QByteArray("lib")+symname.mid(5 /*"init_"*/));
+#endif
         kDebug(150) << "The library" << lib->fileName() << "does not offer an"
                     << symname << "function.";
         return 0;
Index: kpluginloader.cpp
===================================================================
--- kpluginloader.cpp	(wersja 731542)
+++ kpluginloader.cpp	(kopia robocza)
@@ -73,22 +73,28 @@
 #endif
 }
 
+#ifdef Q_OS_WIN
+extern QString fixLibPrefix(const QString& libname);
+#endif
+
 inline QString findLibraryInternal(const QString &name, const KComponentData &cData)
 {
     QString libname = makeLibName(name);
 
     QFileInfo fileinfo(name);
-    bool hasPraefix = fileinfo.fileName().startsWith("lib");
+    bool hasPrefix = fileinfo.fileName().startsWith("lib");
 
-    if (hasPraefix)
+    if (hasPrefix)
         kDebug(150) << "plugins shouldn't have a 'lib' suffix:" << libname;
 
     QString libfile;
     if (QDir::isRelativePath(libname)) {
         libfile = cData.dirs()->findResource("module", libname);
         if (libfile.isEmpty()) {
-#ifndef Q_OS_WIN
-            if (!hasPraefix)
+#ifdef Q_OS_WIN
+            libname = fixLibPrefix(libname);
+#else
+            if (!hasPrefix)
                 libname = fileinfo.path() + QLatin1String("/lib") + fileinfo.fileName();
 #endif
             libfile = cData.dirs()->findResource("lib", libname);


_______________________________________________
Kde-windows mailing list
Kde-windows@kde.org
https://mail.kde.org/mailman/listinfo/kde-windows


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic