gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] CMake, file extensions


From: Richard Crozier
Subject: Re: [Gnucap-devel] CMake, file extensions
Date: Mon, 13 Feb 2017 10:59:27 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 13/02/17 10:12, Felix Salfelder wrote:
On Sun, Feb 12, 2017 at 09:40:35PM -0500, al davis wrote:
The file suffix .. .so , .dylib, .dll ....  others?  Aside from just
the name match, having different suffix makes for an inconsistent
user experience.  The names are different on different systems.

i ran into this, when I added dlopen to qucs. there, i add the platform
dependent suffix to the plugin name, before dlopen. i.e. in the UI, all
plugin names are stripped-down.

somehow inspired by modprobe. only takes the module name (without
suffix) as argument. iirc some day linux changed ".o" to ".ko" for
modules. and that change was not visible on the user end.

what we could do, is replace ".so$" by the platform specific suffix
before dlopen (and warn). otherwise, if the name does not end with
".so", just add the suffix. that should go to c_attach.cc and md.h.

Should we make up a new suffix that is the same on all systems?

that would be another way. any plans to maintain backwards compatibility
with that? side effects? advantages? shared objects are not portable, i
consider it less confusing to use the platform dependent extension.
when i think of an nfs share or a usb stick with a gnucap working
directory (and a jit cache), i do want different extensions...

cheers
felix


You could do something similar to what matlab does. It uses custom suffix for compiled shared libraries (mex files) but with a platform specific extension (e.g. .mexw64 for win 64, .mexa64 for linux 64 bit etc.). Under the hood they are just shared libraries.

The advantage of this approach is that they can be on the Maltab search path and easily found without mixing up with other shared libraries and different platforms versions can coexist. The qucs gui has already implemented a search path for schematic files, like a compiler search path, so subcircuit diagrams can exist in any directory in the path list and be found just by their name, this could easily be extended to cover shared libraries with custom extensions.

Regards,

Richard

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]