@Wildstar128

Quote:

Wildstar128 wrote: Let me explain this to you. I got the tools so therefore it doesn't really matter if the current Amiga Inc. goes belly-up.

So are you saying the tools have been completed? It now supports Symbian, Mac OSX, and AOS 4.0?

Because if thats true, thats important news. The whole point of the product is to be able to make one set of code to run on a ton of operating systems.

Quote:

Bill McEwen said: AmigaAnywhere 2 currently runs under Windows proper, Windows Mobile, Linux for PCs and Linux for embedded systems. A Mac OS X version is on its way, McEwen said, but the company wants to get the Symbian version finished first.

above from: http://www.reghardware.co.uk/2008/01/07/ces_amiga_os_5_surfaces/

Last we knew, the above from Bill was still the case, where Symbian, Mac OS, and (presumably) AOS 4 support were unfinished.

Quote:

Wildstar128 wrote: Making applications using the AmigaAnywhere API can continue to be used from now until ever. The point is, I have the tools, I can make whatever library extensions that I feel so to add to my API libraries set and I include it among any other API mechanism that I feel deemed.

But you have no right to distribute the tools to others, and thats assuming you could find a decent size programming community that would want it. And the handful of folks who have said they obtained the AA2 tools, we still have yet to see any outputted apps from them. And we also saw what happened when you approached the Open Pandora folks, they rejected it for a number of valid reasons as developers.

Last edited by fairlanefastback on 08-Jul-2009 at 07:51 PM.
Last edited by fairlanefastback on 08-Jul-2009 at 07:45 PM.
Last edited by fairlanefastback on 08-Jul-2009 at 07:44 PM.
Last edited by fairlanefastback on 08-Jul-2009 at 07:43 PM.

_________________
Pegasos2 G3 running AOS 4.1 and MorphOS 2.0
Amikit user, tinkering with Icaros VM (AROS)
EFIKA owner
Amiga 1200

@Wildstar128

Quote:

If you want to see some of the existing apps and not wait then go to the Amiga Inc. store and buy the games you see there. Take a look at Genetic Species. Ok, it appears to be a port over of a classic Amiga game onto Amiga Anywhere and new games do keep popping up. Apps that are free to download, well, I haven't seen but then personally I don't know. I haven't dug through all of Youtube to see what kinds of game apps are there.

Almost all of those apps were out before AA2 and its doubtful any of them are AA2 because none appear to run on Linux, a supported AA2 platform. You and pavlor have both said this now. So back it up, which apps exactly are AA2 and why are they not Linux capable if they are AA2?

_________________
Pegasos2 G3 running AOS 4.1 and MorphOS 2.0
Amikit user, tinkering with Icaros VM (AROS)
EFIKA owner
Amiga 1200

@Wildstar128

Quote:

Yes, we can do that. Some probably are and built game titles that uses AmigaAnywhere technology and we just don't know about it because they don't make a big fuss that it was made using AA. It isn't like we were given the list of all the SDA signees.

Sure, but wouldn't it be nice if Amiga supported their AA2 developer community with resources? The fact they they don't seem to do that (besides providing a website to sell stuff for a cut) is part of the reason you are getting laughed off the Open Pandora boards though.

_________________
Pegasos2 G3 running AOS 4.1 and MorphOS 2.0
Amikit user, tinkering with Icaros VM (AROS)
EFIKA owner
Amiga 1200

@Wildstar128

Let me tell you one thing - you don't have any tools, you are philosophically tight to Amiga Inc., you never signed any SDA and you talk crap If you compare your situation to the Commodore 64 afterlife, you are pretty much insane, as you talk about the most succesfull personal computer ever, whereas in the case of AA2, you talk about waporware. AA2 has nothing in common with what 99% of Amigans consider being an Amiga, so for me, you pretty much belong to the group of blind cult followers ...

@-pekr-

Quote:

by -pekr- on 8-Jul-2009 14:50:54 @Wildstar128 Let me tell you one thing - you don't have any tools, you are philosophically tight to Amiga Inc., you never signed any SDA and you talk crap If you compare your situation to the Commodore 64 afterlife, you are pretty much insane, as you talk about the most succesfull personal computer ever, whereas in the case of AA2, you talk about waporware. AA2 has nothing in common with what 99% of Amigans consider being an Amiga, so for me, you pretty much belong to the group of blind cult followers ...

Ok, Pekr - I did sign an SDA with Amiga Inc. They don't provide a list of all the SDA signers. The point is content (by definition in Amiga Inc. parlance) is software and that can be games, demos, ect. If people make games and demos for the C64 then you know that it doesn't require the company to make stuff for the C64. If you sign the SDA then you get immediate access to the SDK and access to the developer areas and can download the SDK.

I don't use Wildstar or Wildstar128 for login at the Amiga website. You have to use your email account. So for your information, the sw is free to SDA signers and is accessible. You need to explore a little to DL the AA2 SDK.

Last edited by Wildstar128 on 09-Jul-2009 at 12:57 AM.

@fairlanefastback

In your comment:

So are you saying the tools have been completed? It now supports Symbian, Mac OSX, and AOS 4.0?

Because if thats true, thats important news. The whole point of the product is to be able to make one set of code to run on a ton of operating systems.

-------------------------------------------------

I have the tools (AmigaAnywhere SDK v1.52 and version 2.0x)

It is a collection of libraries, a version of GCC compiler (aacc.exe) and pdf doc and HTML docs and a collection of example games.

If any of you realized that it is a GCC compiler then you can download a new edition of gcc and incorporate the cross compiler for your target cpu according to instruction on the GCC website(s) and forums. Then copy over the AmigaAnywhere libraries to your project directory as you need to.

Just set your compiler tool chain. It already supports target to x86 and ARM but the built in toolchain is set around Windows because the aacc.exe is a front end command that loads a packaged MinGW compiler.

There is a process to set MinGW to load up a cross-compiler to a target CPU and not just Windows/Windows CE on x86/ARM processors but natively as well as hosted on any OS. Just set it up accordingly.

Should Amiga Inc. have done this, yes but regardless of that, it can be done and instructions are available.

I'm not going to outright put the files up for download for everyone.

I just have to set up the right cross-compiler but others have probably done that. I and that is Me, Myself, and I that I am referring to have not setup the cross-compiler setup. Some folks have already had that before ever signing an SDA and some probably just copied the libraries over and used their C/C++ compiler system setup and load it instead of aacc.exe.

Since the SDK is free when signing the SDA then just picking it up just to get the libraries and so on isn't something to worry or complain about. Amiga Inc. doesn't make money on the SDK this way.

If I setup GCC for cross compiling to each of the target cpu/OS platforms that you listed as other have done and copied over the AA libraries then we basically addressed that issue.

The solution to the problem existed long before AA was issued. Amiga Inc. just did not do that as of yet that I know of. You don't have to wait for them. They probably didn't do it because it was assumed that most of the developers already have done that. Amiga Inc. might have internally done that for actual staff members but I have not and they just haven't released it with every cpu/OS platform on the block in the SDA release. It maybe done in a final release and not in the pre-release.

http://wildstar.emenace.com/AmigaSDA%20login%20AmiPass.JPG

http://wildstar.emenace.com/AmigaSDA%20Developer%20Exchange%20(you%20may%20have%20to%20go%20through%20the%20login%20twice).JPG

The following link to JPGs should be proof to all ends that I do have SDA status.

You can't access these areas without having an SDA.

@Wildstar128

Well, I still think that your comparison to C64 or even Amiga situation back at time Commodore went under, is not valid. In the case of C64 or Amiga, we are talking about millions of users out there, who still were interested in getting new SW. But in the case of AA2, what userbase are we talking about here?

AA2 is not an Amiga. It is not tied to AmigaOS, so that it could attract at least let's-hope-still-existing Amiga userbase. So - who's actually the target here?

I would like to know also one other thing. If AA2 has nothing in common with AA1 (Tao Intent), it means it is developed from scratch. In such a case, how does AA2 differ from JAVA, Python, Ruby, REBOL ... which all run on multiple of platforms? I know that you could say - hey, those are just languages. But I can reply - no, they are being more a platform, than a language. I can take even old R2, and create mini-OS, as we did with REBOL IOS. Auto updating, distributed, and all the stuff.

So please, tell me - why should anyone still be waiting for AA2, if there are other options out there? And especially in current situation, where there is still fog around AA2, instead of vital live community, with web presence? I can tell you, that with REBOL, we wery often talked about so called "DarkNet", meaning that we lived on AltME mostly, which is cool collaborative tool, but we were not visible to the outer world. You can hardly get new devs interested, if you don't open-up a bit your communication channels.

So - how can I trust the company, which has zero PR?

@Wildstar128

waoo ! What a vigorous dev community you are part of : latest top hottest news is from may 2008 more than 1 year ago

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@-pekr-

The point isn't numbers. So is there people writing stuff for Atari, Apple 8-Bit, TI-99/4A and many others. They don't do any programming for their respective platforms because the company.

AA is and potentially has the ability to be used for apps for any and every computing platform that has the suitable hardware resources to run the game. All I have to do is compile my app/game to the platform of choice.

In theory, I could compile a game app using AmigaAnywhere for an NES. There may need to be a few customization to the libraries for some of the video modes of these specific platforms like cell attribute on C64.

It is theoretically possible to run an AA app to a simple IBM PC XT. The point is, anything is possible.

AA2 SDK simply was re-written to not require Tao iNTENT but it is possible to use intent but then Tao inTENT (the VM "player") would be required. That is what made AA1 apps require Tao intent. Amiga probably decided to separate the VM for AA and that would be part of the underlying structure of the so called AmigaOS 5 that Bill McEwen touted.

The VM mechanism is part of it platform independence at OS and app level but there has been a evolution whether you want to call it that to split the two things. AA1 was tied closely to Tao iNtent. AA2 was built so you are not limited to that VM only and if you want to use something else then it is your choice.

AA is not a langauge or a VM. AA1 was an API. Tao intent was the VM. AA2 itself is an API and expands from where AA1 and no longer requires Tao Intent for apps to be made and if you want to run an AA app on top of a hosted OS then you really don't want an extra VM layer. However, you could write apps using the Tao Intent or any other VM system that is appropriate with C/C++ programs (or hybrid C++ and other programming languages). The ultimate point here is, what if I want to use my own VM engine instead of Tao intent or someone elses. AA2 allows for that more easier by not requiring a specific or any VM to operate. It is part of the flexibility that is afforded.

I am not aware of if Amiga Inc. has built their own VM at this time but then I am not privy of that and if I was, then it would be something that in itself would be under an NDA.

They would also need to develop the tool chains to compile the C/C++ code to the "Pseudo-ML" of such a VM.

If they did, it might be part of the underlying structure of and technology used as part of apps for the so called AmigaOS 5.

@abalaban

Quote:

@Wildstar128 waoo ! What a vigorous dev community you are part of : latest top hottest news is from may 2008 more than 1 year ago

The developer community is quite interesting and most apps develop aren't even discussed in the little forum there. The Developer Exchange is probably not even used by most of the SDA signees for their projects

They just dl the SDK, produce the game and put it up for sale. Using either a private forum of their own or IRC chat or email. They are more likely to frequent the many Amiga forums.

The Amiga community also isn't monolithic and there is alot of disconnect compared to some communities where everyone knows who each other are.

Amiga community today has however is more connected then it was at times in the past.

@Wildstar128

Quote:

If any of you realized that it is a GCC compiler then you can download a new edition of gcc and incorporate the cross compiler for your target cpu according to instruction on the GCC website(s) and forums. Then copy over the AmigaAnywhere libraries to your project directory as you need to.

I am not a programmer by any means, but how does taking these extra steps address the code running on i386 Windows vs i386 Linux? You say that you can go grab this GCC piece from someone else than Amiga to target other CPUs they had not yet covered, but how does this address other operating systems for the same CPU family that are not yet covered?

Also, while you may view your developed ad-hoc method as easy, would every developer think of doing this anyway? Would they want to? Are they supposed to think and/or figure that out on their own and happen to come to the same conclusion as you? How do you know this will work if you have not done this making an AA2 app for other CPUs (or have you made any AA2 app at all)?

Quote:

Some folks have already had that before ever signing an SDA and some probably just copied the libraries over and used their C/C++ compiler system setup and load it instead of aacc.exe.

Who are "some folks"? There are possibly less than ten AA2 developers in the world. And I use that term loosely as none seem to have outputted anything. I've only seen evidence of about five or so at all, between posts and websites. Where is this AA2 developer community hiding/existing?

Quote:

Should Amiga Inc. have done this, yes but regardless of that, it can be done and instructions are available.

Isn't that like selling a car with no doors, bumpers, and hood? Why would anyone except the five or so folks we've seen that were already Amiga fanatics and programmers get involved in this, even if there are instructions somewhere on the web on how to massage the product as it exists (incomplete) to be closer to what it was supposed to be when complete?

Quote:

The solution to the problem existed long before AA was issued. Amiga Inc. just did not do that as of yet that I know of. You don't have to wait for them. They probably didn't do it because it was assumed that most of the developers already have done that. Amiga Inc. might have internally done that for actual staff members but I have not and they just haven't released it with every cpu/OS platform on the block in the SDA release. It maybe done in a final release and not in the pre-release.

If its so easy to fix AA2 to do what its supposed to do then why are their no known (verifiable) AA2 apps from anyone that I have yet to see? Why can't they have their full-time employee Jamie yet fix that up in a couple of days if its such a simple thing? Why is no one advertising the power of their new app as easily available on any (or nearly any) OS made? It would seem because there are no AA2 apps.

What good is a tool that is not used to build anything?

Last edited by fairlanefastback on 09-Jul-2009 at 02:50 PM.

_________________
Pegasos2 G3 running AOS 4.1 and MorphOS 2.0
Amikit user, tinkering with Icaros VM (AROS)
EFIKA owner
Amiga 1200

@Wildstar128

Quote:

Wildstar128 wrote: http://wildstar.emenace.com/AmigaSDA%20Developer%20Exchange%20(you%20may%20have%20to%20go%20through%20the%20login%20twice).JPG The following link to JPGs should be proof to all ends that I do have SDA status. You can't access these areas without having an SDA.

Wildstar,

My god, their developer area only had three topics since inception in 01/2008? With a *total* of 23 messages for all three topics? Two of the topics had only one participant in the topic, and the third one only had 7 participants (which was the first topic about the tool's release)? That falls in line with my estimate of less than 10 developers so far.

Worse, the first topic was the month it came out, the second, the next month, and the third was several months later in 2008, and nothing since. Not even from those 8 or so interested folks, *AND* at least one is an Amiga employee (last we knew), their webmaster, Ray Akey.

WOW, I mean I knew in my gut this was probably the case, but WOW.


@all

For posterity, in case the linked graphic is ever not there, here is what it shows:

Quote:

'AA2 Closed Release (2008-01-15)' by Ray Akey on Jan 14, 2008 at 10:00PM 14 messages, 5 attachments, 7 participants 'vpc translation tool' by John Harris on Feb 28,2008 at 11:20AM 8 messages, 8 attchments, 1 participant 'AA2 Developing PocketPC IDE Java-ish Feature Requests' by Simon Jackson on May 12 2008 at 03:22PM 1message, 0 attachments, 1 participant

Last edited by fairlanefastback on 09-Jul-2009 at 03:05 PM.
Last edited by fairlanefastback on 09-Jul-2009 at 03:05 PM.
Last edited by fairlanefastback on 09-Jul-2009 at 03:04 PM.
Last edited by fairlanefastback on 09-Jul-2009 at 03:03 PM.

_________________
Pegasos2 G3 running AOS 4.1 and MorphOS 2.0
Amikit user, tinkering with Icaros VM (AROS)
EFIKA owner
Amiga 1200

@Wildstar128

Quote:

The developer community is quite interesting and most apps develop aren't even discussed in the little forum there. The Developer Exchange is probably not even used by most of the SDA signees for their projects

You know this how?

Lets break this down.

You say the AA2 developer community is quite interesting and most apps made with AA2 are not discussed in the Amiga developer forum that you showed us.

Where then does this community congregate where through communication that occurs in any community that comes together you have see what you view as "quite interesting"? If they don't communicate as a community things that are quite interesting at www.amiga.com/developers/exchange, then where are you seeing this happen that you have formed this opinion? These kinds of statements make it sound like if what you are saying is true, that all AA2 developers are into having some sort of hidden secret community in which they discuss things that you find quite interesting? Honestly, I don't mean to be a bit rude at all in what I have just written. I am just trying to be very specific here. Because I am finding all this cloak and dagger stuff about the hidden world of Amiga, Inc. and its developer partners a bit hard to swallow.

And again, what apps are you talking about? Are any for sale? Where are they? How do you know they are AA2?

Quote:

They just dl the SDK, produce the game and put it up for sale. Using either a private forum of their own or IRC chat or email. They are more likely to frequent the many Amiga forums.

I'm pretty familiar with AW.net, Amiga.org, Amigans.net, Morphzone.org, aros-exec, EAB, Moo, etc. They aren't talking there about any apps. And if they aren't at amiga.com/developers/exchange and they aren't at places like Open Pandora, then where are they??

_________________
Pegasos2 G3 running AOS 4.1 and MorphOS 2.0
Amikit user, tinkering with Icaros VM (AROS)
EFIKA owner
Amiga 1200

@-pekr-

Quote:

-pekr- wrote: @Wildstar128 Let me tell you one thing - you don't have any tools, you are philosophically tight to Amiga Inc., you never signed any SDA and you talk crap If you compare your situation to the Commodore 64 afterlife, you are pretty much insane.

Lets take it easy on direct accusations and name calling please. Thank you.

_________________
Pegasos2 G3 running AOS 4.1 and MorphOS 2.0
Amikit user, tinkering with Icaros VM (AROS)
EFIKA owner
Amiga 1200

@-pekr-

Quote:

-pekr- wrote: @Wildstar128 So please, tell me - why should anyone still be waiting for AA2, if there are other options out there? And especially in current situation, where there is still fog around AA2, instead of vital live community, with web presence? I can tell you, that with REBOL, we wery often talked about so called "DarkNet", meaning that we lived on AltME mostly, which is cool collaborative tool, but we were not visible to the outer world. You can hardly get new devs interested, if you don't open-up a bit your communication channels. So - how can I trust the company, which has zero PR?

Excellent questions!

_________________
Pegasos2 G3 running AOS 4.1 and MorphOS 2.0
Amikit user, tinkering with Icaros VM (AROS)
EFIKA owner
Amiga 1200

From Wildstar128's description of how to compile for different platforms, I don't see how it maintains "write once, run anywhere" support.

It looks more like "write once, recompile one meeeeeeeeeeeellion times"...

@fairlanefastback

Well, there is alot of question and is hard to answer all of them and some of them I don't know an "absolute" answer. First, neither of us knows the absolute number of SDA developes. In theory, there is more signees then those that have actually develop something with AA that we clearly know and recognize.

It is realistic to not be able to tell an AA2 app/game from any other game written with other API because IIRC: AA2 doesn't require a special player and if apps are compiled all the way down to native binary then we don't know because there isn't a bouncing ball on the screen with Amiga logo. It is straightforward. So that always a possibility.

As for GCC and software developers. Most software developers have known how to setup the GCC compiler for other processors. Keeping in mind that if your C/C++ program isn't written to depend on special Windows stuff at source code level and the AA library does not either, then it would compile on any GCC compiler and not the MinGW (Windows GCC compiler).

Since AA was ideally targetted for multiple platforms, it would draw the attention of developer interested in multiplatform development. Most developers who are into multi-platform development is already familiar with GCC (and MinGW Winows GCC compiler) and is also familiar with setting up their compiler for their different chosen CPU platforms. chosen meaning the developer chooses and gets the cross-compiler that they choose because the primary command to load up the gcc compiler is actually a front end program that loads a specific compiler and setting it up with the right compiler to load.

So in essence, GCC can load up a non-GCC compiler for a CPU not directly supported by GCC. MinGW for this instance supports x86 & ARM for Windows/Windows CE OS being the hosted OS for those cpu so it is possible to configure the compiler to load an external C/C++ cross compiler that supports target CPU and target OS and that is setup by the developer.

The lazy side of me would think and be happy if Amiga Inc. did the work for us and they probably have done it but not released it yet.

As for the theory or hypothesis that the AA developers using other areas for discussing their development. First off, developers generally do not discuss their projects outside the selected group of people they choose to discuss their projects with and usually is part of the team that make a project. Especially when it comes to a computer game. Games do not lend to massive open discussions. I say this because most of the titles on the AA website produced since the developer exchange and other developer areas were set up on the Amiga Inc. website. (I didn't show all the Wiki area). Perhaps, the format of the Exchange & Wiki area isn't as intuitive and lend to everyday conversation but we are talking about games. It tends to be private and not open for general discussion by everybody until they are released.

In my experience with projects in a small group, we had our own forum and private area to discuss the actual project(s) and we had an IRC channel and we had private email communication. Other groups probably use similar methods to discuss their projects with other critical members of a particular project team. I can not answer about where they discuss it because I do not have the URLs or direct knowledge and from my experience - the methods I explained are rather commonly used when members of a project team are geographically scattered across the globe so it makes sense to use techniques like what I said and other methods including a Voice Server/Client setup like using Skype, Ventrilo or other programs. It is up to imagination, here because the only ones that know exactly is the ones involved.

For me, I used some of the methods explained above because it was convenient and served the purpose.

My theory is based on a practical experience and it is presumed a similar technique is used. Games do keep popping up and most of it is never discussed on the actual Amiga developer forum. Where the people gather as a whole, places like this forum but usually not to discuss their games and lately, we have had issues about being flamed for talking about AmigaAnywhere because Amiga Inc. and the controversy involved around their issues with Hyperion and how that has some stigma.

It isn't really a barrier to development if you have the balls to talk about stuff. I'm also hoping to bring the topic back into the light so people can be more willing to talk about AA and development around AA but it helps if we refrain from flame around here and elsewhere. I hope we can discuss these things and rebuild some synergy to actually move things forward and I personally hope things move forward positively for AmigaOS, AmigaAnywhere and for both Amiga Inc. and Hyperion for the multual benefit of all in this community.

I do recognize that the issues have been damaging and built an artificial barrier which isn't a barrier.

As soon as I or any of us sets up our toolset to support multiple cpu target platforms, I and hopefully WE can be proud to provide some simple instrructions and if reasonably possible to distribute a copy of a toolset (customized) along with everything of AA SDK to those who have an Software Development Agreement for AmigaAnywhere with Amiga Inc. There is copyrighted content issues and I certainly don't want to distribute something like that to anyone that isn't an SDA signee which would have access to download the SDK for free and me providing it for no charge to the same people is a technical issue but an issue with grounds of reason and provides no material impact to Amiga Inc. Providing to non SDA-signees would be an obvious problem and you understand that. (I hope) My goal in part with this is getting more steam behind all the development. I'm targeting AA which deserves more development of decent apps and games that clearly indicates what can be done.

Also to help draw out AmigaAnywhere developers / SDA signees to come out and let themselves be known. Most of them would frequent forums like these.

I understand that you are a non-developer from what you said and when I go over the steps of setting up cross-compilers thoroughly with GCC and stuff, I'll be willing to share that info.

@Lou

Maybe I'm misunderstanding something in AA2 and I could be. However implementing an underlying VM or maybe I should be bringing the libraries and use Tao or whatever VM I want.

It does provide an hardware abstraction layer in the API. But you might need a VM mechanism to drive an platform independent OS.

Lou, I probably terribly wrote that and I think way late at night (early morning) for me. Apps written using AA API as an abstracted layer between app and platform specific drivers. AA2 is built (currently) around being hosted on top of an OS. In a non-hosted environment, an OS written for a pseudo-machine language (VM architecture) and then providing a compiler tool chain on top of the OS to compile source code and possibly a compiler for C/C++ to pseudo-CPU language.

That would be in the same concept as C/C++ to Tao's VP code (VP being the VM engine of Intent).

They might not included Tao Intent into the AA2 package because the developers are certainly or probably already has AA version 1 with Intent or even a later edition of Tao Intent by Tao and would not be needed and allow the user to choose whatever VM they want or no VM.

However, to run anywhere depends on whether you compile to ML or a special encoded format. I read in the docs about "fatso" which I am not entirely familiar with.

Next message will have an excerpt from the docs.

From the docs,

aacc - Amiga Anywhere C Compiler
Table of Contents

* Synopsis
* Description
* Options
* Examples
* See Also

Synopsis

aacc [-options] [-o outfile] infile...

Description
The Amiga Anywhere C Compiler, aacc, is a front-end program that simplifies the creation of multi-platform Amiga Anywhere binaries. It automatically invokes the necessary tool-chain compiler (normally GCC) and performs pre-processing, compilation, assembly and linking.

By default, aacc builds fat-binary 'fatso' files. This is a compressed binary archive format containing the data for all supported platforms. Using aacc specific options, the compression can be disabled and native binaries can also be created.

In general, aacc supports most of the standard gcc compiler options, but also provides an additional set of options. Listed below are the most commonly used options, starting with the aacc specific options.
Options

-b
Build only for the target platform specified. Note that the output file will be a fatso archive containing only the one specified target platform, unless you also use the '-mnofatso' option.

* win32-x86 Windows Desktop.
* wince-arm Windows Mobile.

-mnofatso
Disable output of fatso archive and create native executables. Normally, this will generate one executable file per supported platform, prefixing the platform name onto the created files. During development, use the '-b' option in conjuction with '-mnofatso' to create a native binary for testing in the targeted platform.

-mnocomp
Disable compression of fatso archives.

-c
Suppress the linking phase. Each source file is run through the preprocessor, compiled, and assembled to produce an unlinked object file.

-D
Define preprocessor symbol.

-g
Generate debugging information in the target platform's native format. Enables source code level debugging.

-ggdb
Produce debugging information for use by GDB.

-I
Add the given directory path to the list of directories to be searched for header files.

-include
The GCC preprocessor supports including a file before the normal preprocessing of its input files.

-imacros
The GCC preprocessor supports including a file before the normal preprocessing of its input files. Exactly like '-include', except that any output produced by scanning file is discarded, only the macro definitions are retained.

-idirafter
Search directory for header files, but do it after all directories specified with '-I' and the standard system directories have been exhausted.

-iprefix
Specify prefix as the prefix for subsequent '-iwithprefix' options. If the prefix represents a directory, include the final '/'.

-iwithprefix
Append directory to the prefix specified previously with '-iprefix', and add the resulting directory to the include search path where '-dirafter' would put it.

-iwithprefixbefore
Append directory to the prefix specified previously with '-iprefix', and add the resulting directory to the include search path in the same place '-I' would put it.

-isystem
Search directory for header files, after all directories specified by '-I' but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories.

-l
Include the shared library named library when linking.

-L
Add the directory to the list of directories to be searched when using the '-l' option.

-nostdinc
Do not search the standard system directories for header files. Only the directories you have specified with the '-I' option (and the directory of the current file, if appropriate) are searched.

-nostdinc++
Do not search for header files in the standard directories specific to C++. but do still search the other standard directories. (This option is used when building the C++ library).

-o
Specify the base name for the final result of compilation. If this output is a linked executable (i.e. not using the '-c' option), the file produced will be a fatso archive by default, with the extension ".fatso" appended to it.

-O
Select the level of optimization. Enabling optimization makes the compiler attempt to improve the performance and / or size of the code. This can reduce compilation time and possibly complicate debugging.

* O0 Do not optimize. This is the default.
* O1 Reduce code size and execution time. Does not perform optimizations that may significantly reduce compilation time.
* O2 Optimize even more for size and performance.
* O3 The highest optimization level. This option may increase the size.

-s
Remove all symbol table and relocation information from the executable.

-shared
Produces a shared object which can then be linked with other objects to form an executable.

-traditional

-traditional-cpp

-trigraphs
Supports ISO C trigraphs.

-u
Pretend the symbol is undefined. Forces linking of library modules to define it.

-undef
Do not predefine any system-specific or GCC-specific macros. The standard predefined macros remain defined.

-U
Cancel any previous definition of name, either built or provided by the '-D' option.

-w
Suppress all warning messages.

-W
All of the standard GCC warning flags are supported. For example, '-Wall' turns on all warning flags.

Examples
The following command will cause the helloworld.c file to be compiled, linked, and assembled. This will result in an uncompressed native executable for the Windows desktop platform.

aacc -mnofatso -b win32-x86 -o helloworld helloworld.c

See Also
aarun, aastrip, gdb