<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">It seems that your solution is workable
but I see little difference with what it is now. Now the
filevector code is incorporated in each packages. You propose to
follow the same way but pack filelvector code in one file (dll or
so) and distribute 9 packages form GenABEL with the same library.
<br>
<br>
Last time I proposed to move filevector in DatABEL. All other
packages (GenA and so on) will load DatAB in R and use filevector
fucntions from DatA. When DatABEL is loaded through
library(DatABEL), the file DatABEL.so is loaded as well. Thus, you
do not need to ask users to install additional lib because it is
in DatABEL already. I think this is a workable approach that will
allow us to delete the filevector code (or filevector so/dll) from
all the packages. <br>
<br>
<br>
This is some quote from the R manual how to register functions to
make it available from DatAB to GenAB:<br>
<h3 class="section">_______________________________________________<br>
</h3>
<h3 class="section">5.4 Registering native routines</h3>
By ‘native’ routine, we mean an entry point in compiled code.
<p>In calls to <code>.C</code>, <code>.Call</code>, <code>.Fortran</code>
and
<code>.External</code>, R must locate the specified native
routine by
looking in the appropriate shared object/DLL. By default, R uses
the
operating system-specific dynamic loader to lookup the symbol in
all
loaded DLLs and elsewhere. Alternatively, the author of the DLL
can explicitly register routines with R and use a single,
platform-independent mechanism for finding the routines in the
DLL. One
can use this registration mechanism to provide additional
information
about a routine, including the number and type of the arguments,
and
also make it available to R programmers under a different name.
In
the future, registration may be used to implement a form of
“secure”
or limited native access.
</p>
_____________________________________________________<br>
<br>
<br>
<br>
Your argument was from "5.8 Linking to other packages:
It is not in general possible to link a DLL in package <strong>packA</strong>
to a
DLL provided by package <strong>packB". </strong>I do not quite
understand what they mean under 'link'. May be the mean link a
library during intsalltion?<br>
<br>
<br>
best,<br>
Maksim<br>
<br>
<br>
<br>
On 19/11/2013 15:14, L.C. Karssen wrote:<br>
</div>
<blockquote cite="mid:528B1DF7.90803@karssen.org" type="cite">
<pre wrap="">Hi Maksim,
Good question... The idea is to generate a .dll file for Windows, but
I'm not sure what would be the best way to distribute that. It would be
interesting to see how other packages do that. For example, the XML
package depends on libxml2:
<a class="moz-txt-link-freetext" href="http://cran.r-project.org/web/packages/XML/index.html">http://cran.r-project.org/web/packages/XML/index.html</a> and the Rcurl
package depends on libcurl:
<a class="moz-txt-link-freetext" href="http://cran.r-project.org/web/packages/RCurl/index.html">http://cran.r-project.org/web/packages/RCurl/index.html</a>
In the XML package .zip file for Windows there is a directory libs/x64
and a directory libs/i386. Both contain XML.dll, so I think that for
Linux you simply specify a dependency on a library, whereas for Windows
the actual .dll is in the package (which is quite logical because
Windows lacks the package repositories that most Linux distros have).
It seems that for MacOS the .tgz file also contains a lib directory with
the .so file.
Best regards,
Lennart.
On 19-11-13 08:56, Maksim Struchalin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Lennart,
How the users under win will install such a library?
best,
Maksim
On 19/11/2013 14:46, L.C. Karssen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dear all,
The Jenkins setup already shows its value: After Maksim changed the call
from std::isnan() to ISNAN() in fvlib's CastUtils.cpp an automatic build
of ProbABEL was triggered and it failed (because ISNAN() is an R function).
I guess this is one more reason to try to convert fvlib into a real
(shared) library.
Does anyone have another workable solution?
Lennart.
_______________________________________________
genabel-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genabel-devel@lists.r-forge.r-project.org">genabel-devel@lists.r-forge.r-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
genabel-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genabel-devel@lists.r-forge.r-project.org">genabel-devel@lists.r-forge.r-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
genabel-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:genabel-devel@lists.r-forge.r-project.org">genabel-devel@lists.r-forge.r-project.org</a>
<a class="moz-txt-link-freetext" href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/genabel-devel</a></pre>
</blockquote>
<br>
</body>
</html>