octave-maintainers
[Top][All Lists]
Advanced

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

Re: New package


From: Guillermo Moliní
Subject: Re: New package
Date: Wed, 16 Jul 2014 10:29:44 +0200



On 15 Jul 2014, at 11:19, gumlym <address@hidden> wrote:

Hi again,

Ok, Ive been trying but still doesnt work. First Im going to describe what I
did before trying to do the package, so that youll be able to understand
better what im attempting.

Before, I had just programmed some functions in c, compiled in myLibrary.dll
and myLibrary.lib. Then all I did was

mkoctfile myccFile.cc myLibrary.lib
autoload("func1","myccFile.oct")
autoload("func2","myccFile.oct"),
etc.

And that works, if I then call from octave func1(), it does what its
supposed to. Im trying to accomplish the same thing, but with a package. 

In the /src folder I have now the myccFile.cc (and all the .h and so on that
it needs). And the library file. The makefile just does:
 all:
   mkoctfile myccFile.cc myLibrary.lib

In the main directory I have a PKG_ADD file with autoloads like this:
autoload("func1",fullfile (fileparts (mfilename ("fullpath")),
"myccFile.oct”))

Several weird things happen: One is that even though pkg install mypackage
doesnt return any errors, if I write func1, it doesnt find it.

That’s because you should first of all load your package:
         >> pkg load yourpkg

Anyway, it would be probably both logically clearer and easier to maintain if you split
myccFile.cc in several files, one for function and named func1.ccfunc2.cc, etc.


Yeah it would make more sense, but I needed all of them to be on the same compilation unit. In any case, is there a way to automatise the pkg load? Or is it just standard procedure to first install the package and then load it?
 

But if I
manually do autoload("func1", "full path to package oct installed in
octave") it does finde the function, but then it cant find the dll. So my
guess is that the first mistake im making has to do with the PKG_ADD, and
then with the library.

I’ve never tried with shared libraries, but I know for sure that static libraries work in
a similar context, so maybe you could try to compile forcing static linking or just remove
the .dll from mkoctfile's reach.


And this brings me to another question. Should I put the myLibrary.dll and
myLibrary.lib files in the /bin directory? So that they will be
automatically copied to the exec path. Or should I keep them in the /src
directory, and then have them copied over to octave with a FILES file. I
have tried both things (and none ultimately work) and they copy the files
but to different locations.


If you still have the source code I suggest you to just add it to your /src directory
and write proper lines in the Makefile to compile the library during the build process.

If you have doubts about how pkg install works and what it expects to find in your 
package, this is a quite complete reference:


I have finally made it work, by putting the .dll and .lib files into the /bin folder. In any case, Im going to change it so that it will be compiled during the build process. But I wanted to have a working version before moving on. I have a last question.. Once Im done with the package, is there any procedure to upload it? Or just upload it to sourceforge via svn?


2014-07-15 12:43 GMT+02:00 Eugenio Gianniti <address@hidden>:

On 15 Jul 2014, at 11:19, gumlym <address@hidden> wrote:

Hi again,

Ok, Ive been trying but still doesnt work. First Im going to describe what I
did before trying to do the package, so that youll be able to understand
better what im attempting.

Before, I had just programmed some functions in c, compiled in myLibrary.dll
and myLibrary.lib. Then all I did was

mkoctfile myccFile.cc myLibrary.lib
autoload("func1","myccFile.oct")
autoload("func2","myccFile.oct"),
etc.

And that works, if I then call from octave func1(), it does what its
supposed to. Im trying to accomplish the same thing, but with a package.

In the /src folder I have now the myccFile.cc (and all the .h and so on that
it needs). And the library file. The makefile just does:
 all:
   mkoctfile myccFile.cc myLibrary.lib

In the main directory I have a PKG_ADD file with autoloads like this:
autoload("func1",fullfile (fileparts (mfilename ("fullpath")),
"myccFile.oct”))

Several weird things happen: One is that even though pkg install mypackage
doesnt return any errors, if I write func1, it doesnt find it.

That’s because you should first of all load your package:
         >> pkg load yourpkg

Anyway, it would be probably both logically clearer and easier to maintain if you split
myccFile.cc in several files, one for function and named func1.cc, func2.cc, etc.

But if I
manually do autoload("func1", "full path to package oct installed in
octave") it does finde the function, but then it cant find the dll. So my
guess is that the first mistake im making has to do with the PKG_ADD, and
then with the library.

I’ve never tried with shared libraries, but I know for sure that static libraries work in
a similar context, so maybe you could try to compile forcing static linking or just remove
the .dll from mkoctfile's reach.


And this brings me to another question. Should I put the myLibrary.dll and
myLibrary.lib files in the /bin directory? So that they will be
automatically copied to the exec path. Or should I keep them in the /src
directory, and then have them copied over to octave with a FILES file. I
have tried both things (and none ultimately work) and they copy the files
but to different locations.


If you still have the source code I suggest you to just add it to your /src directory
and write proper lines in the Makefile to compile the library during the build process.

If you have doubts about how pkg install works and what it expects to find in your 
package, this is a quite complete reference:

HTH,
Eugenio





--
View this message in context: http://octave.1599824.n4.nabble.com/New-package-tp4665192p4665513.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.




reply via email to

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