Page 2 of 3

Re: libauto and application.library

Posted: Thu Apr 09, 2015 12:44 pm
by broadblues
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 

*/



Re: libauto and application.library

Posted: Thu Apr 09, 2015 12:46 pm
by broadblues
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.

Re: libauto and application.library

Posted: Thu Apr 09, 2015 3:47 pm
by xenic
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.

Re: libauto and application.library

Posted: Thu Apr 09, 2015 3:53 pm
by xenic
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.

Re: libauto and application.library

Posted: Sat Apr 11, 2015 8:33 pm
by broadblues
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.

Re: libauto and application.library

Posted: Sat Apr 11, 2015 9:42 pm
by xenic
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.

Re: libauto and application.library

Posted: Wed Jul 15, 2015 11:38 pm
by whose
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).

Re: libauto and application.library

Posted: Thu Jul 16, 2015 12:11 am
by whose
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.

Re: libauto and application.library

Posted: Thu Jul 16, 2015 9:06 am
by salass00
@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.

Re: libauto and application.library

Posted: Thu Jul 16, 2015 11:41 am
by whose
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.