Hi all,
i built a library using a library project from wavecom wizard, thats is simple, but the thing is, how to add this library to a binary app project?
i am trying to do that from wmnew script aditional options but i am still on it,
can someone give some guide about that?
cheers
Hello ofernandez,
I have two other idea in my mind:
Simply edit the makefile of your binary project.
I think it can work altough i have not tried myself the following method.
Create your libary directory in the OpenAT\Plug-in directory with the same directory structure as the other directories like WIP. Tailor the manifest.xml file for your needs. It doesn’t look complicated. Finally you can use the Open AT Wizard to link your libary.
Cheers,
tom
Hi,
in my projects I handle my own libraries in the same way like the libraries shipped by wavecom and use the -otherlib option to include them to my binary projects …
Regards
Ralf
edit the makefile can work for some generation but since the IDE enviroment is set too better use the wizard.
-otherlib try to find a plugin, it does not work for me, i do not know why, but i add the library in the following way,
-rootlib PATHlibrary -inc PATHlibrary/inc -libpref LIBNAME
and the lib is add to the project and i can build rigth.
I get the same. 
It is possible that -otherlib used to work with older versions of the Wizard, but it certainly doesn’t work with the one in Open-AT v3.12/3.13
Note that there’s a catch here: you must use the “wrong” folder delimiters; ie, unix-style forward slashes, rather than the “proper” MS-style backslashes.
Also, it only seems to work for me if I provide the full source project for the library - I can’t get it to work so that I can provide just the library without the source.
So, is there any way to provide just the library and not its source 
There’s an explanation of how to build the Open AT Lua library that shows you how to do this:
wavecom.com/lua/wiki/tiki-in … structions
The interesting line is when configuring the binary using the lib:
You need a -inc for all the header files you need, a -rootlib to indicate where the whole library is positioned, and a -libpref to give the actual name of the library.
EDIT: I was wrong, don’t read this. look down the thread for the actual method.
But won’t that inlcude the library as a full source project?
How can you add a library without exposing the full source?
It won’t: sources are exposed when you use a -src option, and I didn’t. Here I only used -inc, which only imports public header files. Something you can’t avoid in C…
My experience is that, if I use the -rootlib, -inc, and -libpref options, the wizard does not add the library unless the source files are present.
If the source files are present, it then adds the library as a complete source project.
But I shall have to look more closely at how LUA does it…
Of course!
OK, I looked at the LUA Wiki:
That is what I’ve tried, and it didn’t work if the -rootlib folder structure contained only the library and header but no source - the wizard completely failed to inlcude anything about the library into the VisualStudio Solution and, obviously, the builds would then fail due to unresolved references to the library.
It would only work if the -rootlib folder structure contained the complete library source project - and then it would include that complete source project in the VisualStudio Solution
I’m using Open-AT v3.12 - is this a fault that has been fixed in a later version of the Project Wizard?
Or, is it just a fault when using Visual Studio?
I haven’t tried this myself, so not sure if this works or not, but how about using the same way as the included plug-ins?
Example folder structure and where to put libs and headers, just look at WIP.
Actually, it appears that the method I’ve given up there tries to track dependencies across the libs for recompilation, so it depends on the sources being there indeed. A “wmnew -h” (or a look at text file ${OPENAT}/IDE/IDE/${VERSION}/data/wmnew.hlp) will give you the details, namely that you should use “-extlib ${COMPLETE_PATH_TO_THE_COMPILED_LIB_FILE} -libname ${FULL_NAME_OF_THE_COMPILED_LIB_FILE} -inc ${PATH_TO_THE_HEADERS}”.
(Disclaimer: I haven’t tried. I’m interested in success reports).
By copying the structure of the WIP lib, and replacing the libs, and editing the manifest.xml file, I’ve succeeded in getting my own lib to be selected in the Project Wizard…
Yes, that is what I’m also doing! 8)
I didn’t want to mention it incase it might be “frowned upon” by Wavecom - this is clearly hacking into their territory, and not intended for mere customers… 
One thing to note: for the Remote-mode library, you have to rename it from the “rte" (suffixed) name created by the build to a "rte” (prefixed) name required for a plug-in… 
(and add the version suffix, of course…)
But the full name of the required LIB file will differ depending on whether you’re doing a Remote build or a Target build - so how does one specify that?
It would appear that the answer should be to use ‘libpref’; but that doesn’t work - neither Linker (VS nor GCC) finds the library file.
(even if you manually copy the library file into the gcc/out folder) 
It seems that the wmnew script just ignores ‘libpref’ unless it is used in conjunction with ‘rootlib’ and ‘inc’ - but that insists on having the full source of the library!
So it looks like the only options are:
1. Have a full source library;
2. Hack it to make a plug-in.
Even having muddled-through to this sorry state, the Remote-mode Library doesn’t link properly anyway!!
Aaaaaaggghhhhh!!
Time for a separate thread…