libauto and application.library

Have a question about our Software Developer Kit? Ask them here.

Re: libauto and application.library

Postby broadblues » Thu Apr 09, 2015 1:44 pm

mritter0 wrote:I just added application.library support to my program and had the same concern with libauto. Tested like Lyle suggested, still opening v1. I got a huge pop up error about it when ran my program.

I came up with a solution (hack) for libauto:

After verifying that the correct version of application.library opened
Code: Select all
if (!ApplicationBase || !LIB_IS_AT_LEAST((struct Library *)ApplicationBase,53,1))
{
    // error message
    return(FALSE);
}

Then close the library and re-open it with v2:
Code: Select all





IExec->DropInterface((struct Interface *)IPrefsObjects);
IExec->DropInterface((struct Interface *)IApplication);
IExec->CloseLibrary(ApplicationBase);
if (!(ApplicationBase=IExec->OpenLibrary("application.library",53)))
{
// error message
return(FALSE);
}
IApplication=(struct ApplicationIFace *)IExec->GetInterface(ApplicationBase,"application",2,NULL);
IPrefsObjects=(struct PrefsObjectsIFace *)IExec->GetInterface(ApplicationBase,"prefsobjects",2,NULL);
[/code]

It appears libauto still closes the library.



Couple of things here, using your approach you only need to drop the ineterface and obtain the new one, not close the library, or you could even open the second interface as IApplication2 then close it yourself at the end, though that would cause issues if you were using __USE_INLINES__.

The correct thing todo however is to declare ApplicationBase and IApplication yourself in your code and then open and close them yourself.

The way libauto works is that it only loads in code to open libraries if you don't declare the bases yourself. ie

To us libauto;
Code: Select all
#include <proto/somelib.h>

/*
rest of program

*/


To not use libauto:

Code: Select all
#include <proto/somelib.h>

struct Library SomeLibbase;
struct SomLibIFace *ISomeLib;

BOOL OpenMyLibs()
{

}
/*
rest of program

*/


Last edited by broadblues on Thu Apr 09, 2015 1:47 pm, edited 1 time in total.
User avatar
broadblues
Beta Tester
Beta Tester
 
Posts: 416
Joined: Sat Jun 18, 2011 3:40 am
Location: Portsmouth, UK

Re: libauto and application.library

Postby broadblues » Thu Apr 09, 2015 1:46 pm

ZeroG wrote:Simply build your own libauto, look at this nice script to learn how:
http://os4depot.net/index.php?function= ... ibauto.lha


You could but that could cause compatabilty issues if you share code (unless you including your seperate libauto as well ofcourse).


I personally only use libauto for quick and dirty test code, and *always* explicitly open libraries when writing real apps.
User avatar
broadblues
Beta Tester
Beta Tester
 
Posts: 416
Joined: Sat Jun 18, 2011 3:40 am
Location: Portsmouth, UK

Re: libauto and application.library

Postby xenic » Thu Apr 09, 2015 4:47 pm

ZeroG wrote:Simply build your own libauto, look at this nice script to learn how:
http://os4depot.net/index.php?function= ... ibauto.lha

That script is a little outdated and doesn't work as it is. Here are the problems I found:

If the script fails, the "popcd" command is never executed and unless you notice that you were left in the wrong current directory you can't run the script a second time; it tries to delete the old directory which fails because it was left as the current directory.

The script fails because it uses "-newlib" as a C flag if you use the NEWLIB argument.

The script assumes that the default C library is is clib2 and doesn't set any C library flag if the NEWLIB argument isn't used. It will attempt to make a Newlib libauto.a file no matter what is or is not entered as an argument.

The script fails because of these errors:

    autoinit_cia_main.c:26: error: expected identifier or '(' before ';' token
    autoinit_cia_main.c: In function 'cia_main_constructor':
    autoinit_cia_main.c:32: error: expected expression before '==' token
    autoinit_cia_main.c:39: error: expected expression before '=' token
    autoinit_cia_main.c:40: error: expected expression before '!=' token
    autoinit_cia_main.c:43: error: expected expression before ',' token

That script needs to be fixed & replaced and the CIA resource files in the SDK need to be fixed.
AmigaOne X1000 with 2GB memory - OS4.1 FE
xenic
 
Posts: 938
Joined: Sun Jun 19, 2011 1:06 am

Re: libauto and application.library

Postby xenic » Thu Apr 09, 2015 4:53 pm

broadblues wrote:You could but that could cause compatabilty issues if you share code (unless you including your seperate libauto as well ofcourse).

True and how hard would it be for a new "official" libauto.a to be generated and distributed through AmiUpdate to eliminate the problem.

My testing of the script reveals a problem with the CIA interface file that needs to be fixed in the next SDK.
AmigaOne X1000 with 2GB memory - OS4.1 FE
xenic
 
Posts: 938
Joined: Sun Jun 19, 2011 1:06 am

Re: libauto and application.library

Postby broadblues » Sat Apr 11, 2015 9:33 pm

True and how hard would it be for a new "official" libauto.a to be generated and distributed through AmiUpdate to eliminate the problem.


Don't know, it's 'depricated' or at least discouraged for general use, so it may or may not get updated, I wouldn't reply on that update, just handle you own library opening with proper version checking.

My testing of the script reveals a problem with the CIA interface file that needs to be fixed in the next SDK.


I beg to differ :-) If you wonder why then think for a moment about what the CIA is (and I don't mean them murican spies) . I'm sure your resourcefuil enough to figure out.
User avatar
broadblues
Beta Tester
Beta Tester
 
Posts: 416
Joined: Sat Jun 18, 2011 3:40 am
Location: Portsmouth, UK

Re: libauto and application.library

Postby xenic » Sat Apr 11, 2015 10:42 pm

broadblues wrote:Don't know, it's 'depricated' or at least discouraged for general use, so it may or may not get updated, I wouldn't reply on that update, just handle you own library opening with proper version checking.

Anything that's included in the official OS4 SDK should work properly or be individually updated. I wonder how many programmers aren't reading every topic in these forums and not aware of the application.library interface issue.

I beg to differ :-) If you wonder why then think for a moment about what the CIA is (and I don't mean them murican spies) . I'm sure your resourcefuil enough to figure out.

You're probably right. The problem isn't with the CIA files but with attempting to add resource opening to libauto.a.
AmigaOne X1000 with 2GB memory - OS4.1 FE
xenic
 
Posts: 938
Joined: Sun Jun 19, 2011 1:06 am

Re: libauto and application.library

Postby whose » Thu Jul 16, 2015 12:38 am

AFAIK libauto was never meant to support fine-grained version control, but instead was meant to support "up to date" Amiga programming. That means, if something changed with a new library version, the new library version should be used and use of libauto was discouraged if one wanted to use the actual NDK/SDK for programming with older versions of a specific library (so the programmer gained full version control again, as needed).

Just update libauto with auto-open of the v2 interface of application library, please. Btw., some docs regarding this topic, spread with the newest SDK, would be very nice *hint* ;-)

(I mean some text explaining the problem of spreading source code that uses libauto features but doesn´t mention the NDK/SDK version used in it´s docs. The problem isn´t really new).
whose
 
Posts: 92
Joined: Sun Sep 04, 2011 4:11 pm

Re: libauto and application.library

Postby whose » Thu Jul 16, 2015 1:11 am

I beg to differ :-) If you wonder why then think for a moment about what the CIA is (and I don't mean them murican spies) . I'm sure your resourcefuil enough to figure out.

You're probably right. The problem isn't with the CIA files but with attempting to add resource opening to libauto.a.


The CIA XML is just missing the basename value... IDLTool should learn to differ between Library and Resource, that´s all.
whose
 
Posts: 92
Joined: Sun Sep 04, 2011 4:11 pm

Re: libauto and application.library

Postby salass00 » Thu Jul 16, 2015 10:06 am

@whose

The CIA resource is rather special in that there are actually two resources one called "ciaa.resource" and the other "ciab.resource" (one for each of the Amiga's two CIA chips) which both use the same API and hence the same includes and interface .xml file.

Also note that in SDK:interfaces/ there are also generic interface definitions for things like datatypes, dockies, AHI drivers, etc. making generating a libauto from all the .xml files contained in there not such a great idea.
User avatar
salass00
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 460
Joined: Sat Jun 18, 2011 4:12 pm
Location: Finland

Re: libauto and application.library

Postby whose » Thu Jul 16, 2015 12:41 pm

salass00 wrote:@whose

The CIA resource is rather special in that there are actually two resources one called "ciaa.resource" and the other "ciab.resource" (one for each of the Amiga's two CIA chips) which both use the same API and hence the same includes and interface .xml file.


Maybe it´s time for a second .xml then, although they are identical in form and function? Sometimes it´s better to break SDK compatibility then to make coder´s live harder (I don´t think that there is so much vital OS4 code that makes use of the CIA resources).

Also note that in SDK:interfaces/ there are also generic interface definitions for things like datatypes, dockies, AHI drivers, etc. making generating a libauto from all the .xml files contained in there not such a great idea.


Yeah... that´s why I would prefer to see IDLTool handle all of that correctly. There is a "basetype" tag, but actually it´s used to distinguish between Library and Device only (and distinction works...).

I don´t see the point having a tool that is able to produce libauto code when this function should not be used. If there is any serious harm done to code if libauto is used, one should know the reason why this happens. "Version control" is no serious harm and there is a good reason to use libauto: it´s fast and easy to use.
whose
 
Posts: 92
Joined: Sun Sep 04, 2011 4:11 pm

PreviousNext

Return to SDK Support

Who is online

Users browsing this forum: No registered users and 1 guest

cron