Re: [MiNT] [Mint-cvs] [FreeMiNT CVS] freemint/sys/sockets/inet4

[Paul Wratt <paul.wratt@gmail.com>]

On Sun, Jan 3, 2010 at 4:55 PM, Henk Robbers <h.robbers@chello.nl> wrote:
> Jo Even Skarstein wrote:
>>
>> Helmut Karlowski wrote:
>>
>>> Am 03.01.2010, 00:04 Uhr, schrieb Henk Robbers <h.robbers@chello.nl>:
>>>
>>>
>>>> On my todo list is compiling MiNT and XaAES.
>>>> I probably start on MiNT 1.15.12 and XaAES2002.
>>>> The first because it is the last stable release,
>>>> the latter because it is a Pure C program and I know it.
>>>
why would you not use 1.16.3 as your start point, which is stable, or
is there something wrong with it?

BTW, just headup on compile time, I use ARAnyM on 3GHz machine with
512Mb RAM, config uses 64Mb FastRAM, and EasyMiNT seemst to rate the
CPU at 75Mhz, it still latkes about 50 minutes to compile 1.16.3. Note
that he grater part is actually the XaAES compilation stage, which is
why I have broken out the gradients, and created recolor script for re
compile one or two .O files, then reassemble all into binary.

>>> Do you plan to provide a cli-version of AHCC?
>>
>>
>> There is already a ttp-version of AHCC.
>>
>
> Indeed, there is. But I cannot run it.
> So it is untested.
>
Why, I have used it with ARAnyM. mind you that is only with 1.16.3 atm

I have used and tested the command line version, which is functionally
identical to GUI version, including the project compiler. You must
remember that Henk has no love for the command line, and has told me
off already for suggesting that I myself make some additions to it. :)

>From AHCC GUI point of view tho, the idea is to get the project file
to do all the work, not the command line (as such)

> It is however exactly the same compiler as is called
> by the GEM version. The called version is passed a true Unix
> cammandline internally which is then parsed as if it was
> indeed a commandline from a commandline shell.
>
> If you run the GEM version with verbosity, the passed commandline
> is displayed in the journal. So you can see what is working.
> I dont know if multiple input files work.
> The called compiler always gets only 1 input file.
> I also dont know how well it works with relative paths.
>
> In the GEM version locations where to look for include files
> are derived from the full path of the compiler and the full path
> of the project file.
>
> --
> Groeten; Regards.
> Henk Robbers. http://members.chello.nl/h.robbers

You should be able to run it with the Venus/Gemini shell, M??? (can
remember the name atm), without using desktop replacement. It is
considered the best console shell on the Atari ST (bash being GCC/GNU
friendly only)

BTW, I find the GEM dev environment to be awkward to use  in AHCC, so
it was my plan to wait until you Henk had added v4e support then rip
the interface to pieces and re assemble it with some rapid dev type
IDE additions, similar to say the Java based IDE on linux/win (also
can remember the name), the one whioch promised v4e support.

and enhanced IDE or rapid dev tool does not make a lot of sence if you
already have a working setup, and limited screen space, but these are
not part of an ARAnyM setup, and wont be on and v4e either (nor CTPCI
or Super Videl)

As much as I think it would be nice to get the source for Resource
Master to be placed in GPL or similar, I think that atm at least, a
command line resource builder would be more useful atm, as there is
not one that can do all RSM or Interface can (including icons). This
is one of my top proiorites of programming, along with IDE and or
rapid dev app.

I have an idea to document and package a IDE configurator that allows
quick integration into various AV desktops, especially for compiling
and editing sources, as I know there are people who have working
setups, however I still see a longer term need for a dev app that can
do both AHCC/PureC etc AND GCC/GNU

Some default source that provides PureC, AHCC and GCC compatible
source out of the box would be nice also.

I believe that even tho the previous mention IDE is Java based, it has
rukles for syntax check, which could be used to allow inclusion and
completion, specifically to generate cross compiler compatible
source.. so it may still be an option, as I have a newer version of
kafine/kaffe that should port OK, and I believe I have the other
libraries required, this may be a while in coming from me tho... I
have to get through the current round of we stuff first, and submit a
patch or 2 to XaAES cvs

Paul