Just a gentle reminder to plugin authors: the names you pick for your shared libraries do matter! You should always pick a descriptive name for your shared libraries on all three platforms, which will help ensure that the name is unique.
You see, when an application is compiled that uses a plugin, the compiler simply reuses the shared library name when writing the plugin out to disk. So if you have multiple plugins that share the same shared library name, you can run into problems.
I spent some time looking into a bug report where there were *five* plugins whose shared library name were all "plugin.dll" on Windows. As you can imagine, the project didn't work too well! But this isn't just a Windows problem -- the shared libraries are written out to the application bundle on Mac, for instance.
So if you're a plugin author, you should take care with what you name your shared libraries within your plugin, regardless of platform. Just a little issue to keep in mind.
Perhaps I'm being unreasonable, but shouldn't the compiler anticipate this and use unique names for the files?
Shouldn't the compiler/linker be able to detect such a name conflict and, if it's not able to resolve it, at least tell the user of it?
It's not unreasonable for the compiler to throw an error when it happens, but the compiler shouldn't modify the filename automatically, since it's reasonable for a properly-written plugin to expect the filename to remain the same.
But then again... any plugin author who is going to hard-code their plugin name into the plugin itself is also more likely to name their plugin something unique anyhow. So perhaps it's not entirely unreasonable for the compiler to just automatically rectify the situation, but toss a warning the user's way about the problem.
Plugins don't get to control this on Mac OS; the linker simply generates a unique name. Under what circumstances would it be useful for a plugin to be able to locate the file into which its code had been written?
@Mars -- you sure about that? Because I looked at the app builder for the Mac, and it just spits the files out with their original names from what I can tell... As for why it might be useful: security comes to mind. I've written several plugins which store their registration information in the plugin file itself as part of the resources. Part of that is also taking an MD5 hash of the plugin the verify that it's in a stable state on disk. Granted, I am sure I could hack around that with some clever code, but my assumption has always been that the shared library remains intact, name included.
Of course, it's just as easy to make it spit out a unique name as it is to spit out a build error. The real question is: which is more correct? I think the build error is: plugin authors shouldn't be assuming that the compiler is going to cleverly fix their mistakes for them. And modifying the plugin name so it's unique may work 99% of the time, but in that 1% of the time it will make a bug that's very, very hard to track down.
@Mars -- I took another look at the Mac app builder, and you're right, it does modify the filename to be unique (just in a different fashion than I was anticipating).
Since it does do that on the Mac could it do the same on Windows ?
I suppose there's still some small random chance that two authors might pick the same name even though the plugin might define classes/modules/methods with slightly different names