Something like this?

@Hans


I haven't tried much with sgit yet, but when I moved from SVN to git I had the same questions! You have to commit changes first before calling git push. Rather than having to add every change to the staging individually, you can call

git commit -am "...."

the -a adds all changed files in one go.

Cheers

Billy

@Hans

I've had that before if git has been compiled without access to libcurl (https://curl.haxx.se/libcurl/). If you install that then rebuild git you should be fine.

billy

@Rigo

Worked for me but I had to do it from my Dropbox app as I couldn't get the download file selector to work using Odyssey as I suspect the JavaScript failed.

Billy

Count me in!

@salass00 and @chris

Thanks chaps that makes total sense. I was getting thrown by the constructor (".zzzz") bit and whether that that was doing something special when the shared library was being opened.

Hi all

I've just uploaded a new version to os4depot with a load of bug fixes and new features, have fun!

Hi all

I'm trying to write a library that is able to be opened automatically by other programs using the -lauto flag when compiling them and I'm running into problems. It must be missing something out, but I'm stuck!

I took the example at http://wiki.amigaos.net/wiki/How_to_create_an_AmigaOS_4_library and built the subsequent sample.library. I noticed that idltool created two auto-init source files, autoinit_sample_base.c and autoinit_sample_main.c which weren't being referenced in the generated makefile. So I added them to the makefile sources and built the library.

I then used the following test program based upon the test program in the article. If you run it without any command line args, it will explicitly open the sample library and its interface. If you specify a command line arg, I thought that it should use the auto-init code. I compiled the program using

gcc test.c -o test -lauto -gstabs -I../include

However if I try to run it using the auto-init code, ISample is never initialised. My question is what am I doing wrong?

An archive containing all of the files is at https://www.dropbox.com/s/sy130r5aorl26op/sample.lha?dl=0 and the code for test.c is below




cheers

Billy

@Chris

Yup that and adding the auto init code are the two outstanding bits of functionality that I can think of. And of course there will be no doubt be guys that will need squashing.

@Chris

Ah I get it now!

I've fixed it so now it parses and compiles libnsbmp seamlessly now along with a load of other bug fixes and features such as an option to automatically open and close newlib. I'll upload it to os4depot in the next couple of days.


cheers

billy

@Chris


Yup it's a good test, I found a bug that the code generation for functions with a single input parameter wasn't getting generated properly and that's fixed for the next version.

Probably my sleep-deprived brain but what issue are you thinking of when you say libraries using functions from other libraries?

cheers

billy

Hi all

I agree IDLTool and fdtrans are great at what they do, the issue is that you still need to write the xml or sfd file and synchroize it with the function definitions. The goal of libgen is to do that all for you so it will generate the xml or sfd file for you automatically from the source. As well as this it replicates what idltool does in terms of generating the library init code, header files, etc. It also wraps the called code into the library.

For instance, say you've told it to build "foo.libray" and it finds a defintion such in "foobar.h" like



it will generate the appropriate library files with a source file containing:



and the corresponding header file as well as a makefile to build it all.


The main goal was for my cross-platform projects whera I can generate a
shared library on windows or linux just by having a makefile pointing at the source files and I wanted the same on my amiga. I don't have to worry about keeping sfd or xml files in sync with the directory tree containing the source files, I simply point libgen at the directory and tell it to generate all of the amiga-specific files for me. The idea of writing the sfd or xml file by hand for projects containing hundreds of functions didn't
filll me with joy!

So rather than generating the skeleton code, it goes further and tries to generate the working code along with, as best as it can, a ready-to-go makefile without me having to fill in any other code.

Hope this makes vague sense!

@Chris

Thanks for this, yup my whole reason for starting this was I had a project with about 600 functions that I wanted to port and the idea of generating the xml files for them just made me reach for some beers! That netsurf code will give me some really useful food for thought for the parser part, which is definitely the most "ugh!" part of the program! Trying to replicate YACC or similar is not fun. It looks like it's not able to parse the callback functions properly and that I should get it to understand structures and enums instead of trying to parse them as function declarations.

I noticed that the output said failed "failed to generate init.c" which should I suspect actually say "failed to generate lib_init.c" (first bugfix done, hurrah!), is there a lib_init.c in the folder? It should be a straight copy of "data/lib_manager.c.template", which should be in the archive with libgen.

And yup, the whole point of this is not to have fix stuff up afterwards, I'll download that bmp decoder code and set about getting the parser to cope with it.

Thanks for the feedback, it's definitely appreciated.

@Kamelito

Yup. The main differences are that with idltool you have to write the xml file , then fill in the skeleton interface code to all the actual code that does the wrk. With this tool you point at the actual code and it generates the full interface code for you.

Hi

Waking up a long dormant thread! I've just finished a piece of software that builds an amiga library/interface from a set of pre-existing header and source files so you don't have to worry about generating teh XML file and filling in the stub routines and so forth. It should be on os4depot shortly and any feedback would be gratefully received.

Cheers

Billy

@BSzili

I've been using it in a project recently, so I can help if you'd like. AFAICR It uses dropbox's older oauth rest api, rather than oauth2, from its libaouth dependency, and it needs jannson's json stuff.

This is *awesome* news!!

Quote:

The biggest difference as a developer is the way of connecting signals and slots has changed whereas before it was

connect (signal_object, SIGNAL (...), slot_object, SLOT (....))

in Qt5 it's

connect (signal_object, SignalClass :: SignalFunction, slot_object, SlotClass :: SlotFunction);

It feels quicker than Qt4 (on Windows at least). This will definitely make the app I'm developing way easier to release on the Amiga as I'd already converted all of the signal/slot to the new style

billy

@Chris

Quote:

Thanks for this, I'll take a look and see how I get on with these.

cheers

billy

Hi all

I've got a load of code that I'm trying to convert into a native amiga program and I've got a question about converting some shared utility function libraries. I've got them as dll and so files on windows and unix. Given the nature of the program, keeping them as shared objects is quite expensive as the program also consists of a load of plugins (as shared objects) and the overhead of reloading the utility libraries as shared objects for each one is too much. The libraries only export functions, no data, so they should be ideal candidates for normal amiga shared libraries.

After playing around with idltool, I'm starting to see how the xml and code fit together but I have a couple of questions.

1. Is the struct interface *self parameter a requirement? My code itself doesn't need it, since it doesn't have any private library specific data, and it would mean that I could just use the same prototypes that are in the library already. Or do I need to create a load of stub routines that include the self parameter that simply call the original prototype. For example, is it enough to have something like

void ConjugateQuaternion (Quaternion * const quaternion_p);

or must I have something

void ConjugateQuaternion (struct EPRIFace *self, Quaternion * const quaternion_p);


2. Looking at idltool it generates the c/h files from an exsiting xml file; for my situation I want to go the other way since I already have the c/h files and would need to generate the xml file. There about a 1000 functions so it could be quite time consuming to generate this interface xml file by hand, so I've started toying with the idea of writing a parser program to scan the header files and produce this xml file. Am I duplicating something that already exists here?

cheers

billy

Quote:

I think you're a bit premature there; I ran a university website up until about a year ago and the proportion of external traffic that was firefox was higher than all the other browsers, IE included. Firefox really isn't going to disappear anytime soon.

billy