Thursday, September 12, 2019

Setting up a 64bit Linux development env for AROS

by on Thursday, September 12, 2019
One of the scariest part about coding or compiling applications for AROS (in particular for the x64 version, where the following procedures are mandatory) seems to be setting up the AROS build system which is, on the contrary, quite straightforward. So here I will explain how I did it, which is the simpliest, barest, dumbest way to do this thing. Better implementations would include using different directories for building, in order to separate different targets (for instance, ARM, M68K and i386) on the same computer, but I'm leaving this to your will. At the end you should be able to compile your 'HelloWorld.c' program for 64bit AROS.

SETTING UP THE UBUNTU VIRTUAL MACHINE

Let's be clear. Linux gives great freedom to users, and you might have practical and ethical motivations to dislike this distribution and prefer another one, but please get real and let's be practical guys: if you choose Ubuntu, you're SURE this procedure will work as expected, with no customizations, no personal modifications, no unavailable packages, no avoidable issues. You will use the upcoming machine to compile AROS and AROS programs only. Nothing else. You can live with this distro, with its GUI, with its habits. So head to Ubuntu's download page and grab Ubuntu 18.04.x LTS (long time support), which is exactly the one I'm using as well.

> Download Ubuntu

(you can follow the 'alternative downloads' link on the right of the page, if this guide got old and another version of the distro has superseded the suggested one).

Then, you need a virtualization platform. There are several ones out there, with QEMU/KVM, VMware Player and VirtualBox being the most popular. Again, I suggest to choose the one that works better, both with Linux and AROS, which is VMware Player. Grab the latest version here:

> VMware.com download page for VMware Workstation Player

It's FREE and available for both Linux and Windows, so you won't have any issues running a Ubuntu virtual machine on your computer. If you have a Mac, there is VMware Fusion but you will have to pay for it. The alternative is VirtualBox, but I generally suggest it as a 'last option' because 1) sometimes newer releases introduce regressions with guest OSes which worked good before, and 2) this is often the case with AROS (where we received dozens of reports about sound and mouse pointer not properly working). I am also sick of discussions with VirtualBox users, when I tell them their virtualisation platform has issues.

Once you have these two components, you can install VMware Workstation Player. You need a 64bit host operating system (either Linux or Windows) with a stable Internet connection you will share with your virtual machines. Create a VM with the following specs:

Operating system --> Ubuntu 64bit
Processors --> 2 - 4  (if you have a new Ryzen processor... why not?)
Memory --> 2 - 4 GB
Hard drive space --> 40 - 60 GB thin provision¹
Network
USB controller 2.0
Sound

(¹) Thin provisioning is the default behavior for VMware Player, when setting up a virtual machine: it allows dynamically increasing .vmdk file space when you actually save data to it. So, if you create a 60 GB hard drive file, it will not take 60 GB of your real hard drive at once, but its size will grow as much as you use it. In a nutshell, it will grow up to the size you choose, with time.

Boot your new virtual computer and let Ubuntu update itself. After a little while, you will be able to add components needed by AROS. When you're ready, open a Linux shell and enter the following commands:

sudo apt-get install -y libpng-dev zlib1g-dev libxcursor-dev libgl1-mesa-dev libasound2-dev
sudo apt-get install -y gawk bison flex netpbm automake cmake genisoimage sshpass
sudo apt-get install -y python-mako libswitch-perl gperf gcc-multilib g++ ccache
sudo apt-get install -y jlha-utils wget

Now start Mozilla (or any browser you installed on your VM) and download AROS sources from the following link:

https://github.com/aros-development-team/AROS.git

Create a directory in your home, for instance 'sources' and extract all contents. In this guide, I will use this path: ~/sources, you will need to adapt it if you choose a different one.

Now be sure your internet connection is working and keep it alive, because the next steps require a Internet connection. Give the following commands:

cd  ~/sources

./configure --target=pc-x86_64 --enable-ccache --with-gcc-version=9.1.0 --with-binutils-version=2.32 --with-portssources=~/sources

make -j 2 && make -j 2 distfiles


this will create your first AROS ISO. If you need to redo it quickly after modifying some file, the following command will be enough:

make -j 2 bootiso-quick


COMPILING YOUR SOFTWARE


Now that we have a working AROS build system, it's time to use it to compile your software. You will do this providing both source files and a metamake script called 'mmakefile.src'. One for each project you need. Metamake scripts are a sort of recipe that tells the crosscompiler what to do. Unluckily, I am not able to tell you how to correctly write one, but I can give you at least a vague idea. Inside of ~/sources, create a 'personal' drawer for your programs.

md personal

and, inside of ~/sources/personal, create a different 'projectname' subdirectory for each program, for instance ~/sources/personal/myproject

Now, let's imagine you have a myproject.c and myproject.h files for your program: you should place them into ~/sources/personal/myproject and create a mmakefile.src script in the same directory, for instance:


#MM local-personal-myproject : includes linklibs

FILES := myproject    ← myproject.c without .c
EXEDIR := $(AROS_CONTRIB)/$(AROS_DIR_DEVELOPER)/Build    ← destination path for binary file
NOWARN_FLAGS := $(NOWARN_FORMAT)
USER_CFLAGS := $(NOWARN_FLAGS)

%build_prog mmake=local-personal-myproject \
progname=myproject targetdir=$(EXEDIR) \   ← executable name
files=$(FILES)

%common

Pay attention to the first line (#MM local-personal-myproject : includes linklibs), the bold part is the one you will call with the make command, from the root of the sources directory

cd ~/sources

make local-personal-myproject


If you need a better explanation to this, please also read the following post:

> "How I compiled deark for 64bit AROS"

Tuesday, August 27, 2019

IconPoser 1.0 first release!

by on Tuesday, August 27, 2019
IconPoser has been released and it's now available for download. A new page for the project has been added to Icaros Desktop website, which includes program information and download link.


This tool was originally intended as an internal tool for Icaros development. However, after I talked here about its existence, it generated some welcome interest. This motivated me to make it better and... available to everyone! Obviously, you need to use Icaros Desktop to make the most of it: it's a LUA based script aided by a shell one which use several utilities provided with the distribution. This does not mean an AROS nightly build can't use it: it means  you will need to provide other components as well (whose binaries might not be available, for instance, on ARM or M68K AROS).

Just for your curiosity, here's what I had to fix before releasing the tool:

1. picture requester does not remember last used path by itself, so I had to instruct IconPoser to save it somewhere. This made the "Images Path:" button on top quite useless, but well, you might still want to change starting directory after all (picturereq might fall in a very crowded directory and slow down);

2. paths and file names with spaces didn't work. I had to add gsar to the list of used components to work around this, but this is nothing a Icaros user should care at all: it is already provided with the distribution;

3. IconPoser could overwrite a generic file with a icon, when saving it. Let's be clear: this tool won't bug you with any pointless "are you sure?" questions when overwriting icons, but now will stop operation if you forget to add the .info extension, and you try to overwrite your favourite program, video, song or whatever with its icon.

Please also beware of damn internal PNG formats, they can be quite annoying. Yesterday, while I was creating new icons from a old collection of images in PNG format, I lost 3 hours behind some images that didn't generate a dual state icon at all. It showed like this, making me really, really, really sad:


I was sure I had made some mistake within IconPoser but, after trying to join the original pictures with the 'join' command on several AROS flavours, I could be sure they didn't work on any of them, no matter the procedure I used. This made me decide to batch-convert all images with RNOEffects, loading and simply saving them as PNG to a different folder. This absolutely fixed the non-issue.

I also noticed that my former posts about IconPoser generated a topic on AROS-EXEC.org. Follow it and please use it also to make questions and suggestions for this program.

> Link to the discussion on AROS-EXEC.

Little note about licensing: With the program, I also provided a .guide which explains how to use it. It also says some unpleasant things about the fact that you can use and edit it as you like, but you can't redistribute it on sites (for instance: the Archives and Aminet) or on your own AROS distribution without asking me for permission. That's simply because IconPoser is still at its infancy and it will be furtherly developed, I want to keep control of the process and decide whether to accept other people's enhancements or not. When it will be stable/developed enough, this will probably change to a full open source license.

Monday, August 26, 2019

Inconposer now working as intended

by on Monday, August 26, 2019
As you may have read some days ago, I started working on Iconposer, a tool which would let me join two different PNG images into an AROS compatible dual-state icon, and I finally reached the point I was aiming to, from the beginning. It can now handle the following cases:
  • adding a new icon to an executable, a project or a drawer, with proper stack size or default tool
  • replacing an existing icon with a different image, but keeping the original options and tooltypes
  • creating or replacing a icon for a tool or a project, but copying tooltypes form a different icon
and, best of all, it works on both 32bit and 64bit flavours of Icaros Desktop, which is by the way the first motivation I wrote Iconposer at all! 

64bit hosted Icaros running Iconposer, on my new 64bit Ubuntu 18.04 virtual machine
Iconposer needs some other components to work: PictureReq from Yannick Erb (who has been so kind to help me compiling for 64bit AROS - thank you so much!) and Processicon (which I could compile some weeks ago as you may already know). It might also need gsar in the future (no problem for 64bit as well), but not for now. If you wonder if I am going to release it for everybody, the answer is that I am still evaulating this. There are many needed components and Iconposer, at the moment, is a very "personal tool" I'm using to speed up my works on Icaros Desktop, and it still has many shortcomings (like, for instance, the inability to handle paths with spaces). So it's probable I will add it to the distribution when at least the latter issue will be resolved.  

Friday, August 23, 2019

Not-so-poor Icon processor

by on Friday, August 23, 2019
While working on 64bit AROS, I discovered that many icons changed and some new ones are needed. Obviously, finding a proper icon for everything, with the magnificent and enormous set Ken Lester allowed me to use, is quite trivial, but some new developments need for proper imaging and these days I really missed a simple tool which would let me assemble double-state, AROS-compatible icons from two different PNG images. Yes, we now have a great Icon Editor but it's 32bit only and I needed something that would have been quicker, easier and basic. My first thought was to use a shell script: open the normal state PNG, open the selected one, join them together and rename as needed. Easy, isn't it? Well, right, but icon handling on Amiga also includes nice-to-have features like default tool, stack size and - best of all - tooltypes. All these should be nicely handled and the 'simple script' solution wouldn't fit at all. So I decided to create a LUA based Icon processor which would take advantage of some components I have already built in my 64bit environment: processicon and picturereq (Yannick told me how to compile it right and yes, now we have a 64bit executable for it!). The result, for now, is something like this:


Not bad, isn't it? Well, my creation is only the smaller one on the left, and there's still much to add. For now I have just implemented the most basic functions of the interface: it loads and shows normal and selected PNG images (transparency doesn't work properly - but that's not something I will spend my time to fix or work-around), it lets me choose the icon type and add a stack size. There are two options I still need to add: actual saving of icons and a tooltype loader/editor. Honestly, I haven't decided yet if the LUA script will be completely stand-alone or, more probably, a LUA + Shell scripts solution, because there are parts that can be more comfortably handled with a different approach.

Tuesday, August 20, 2019

Little changes for Magellan

by on Tuesday, August 20, 2019
I've made some little changes to Magellan that should make us Icaros users happier. First of all, I found on DOpus 5 website a link to a newer version (a nightly build of v5.92 from 2016), which should be more polished and advanced than the one (v5.91) currently included in Icaros Desktop. I'm testing it right now without pain, so it should be good for 'production'. This was, indeed, a good time for two little changes I was thinking about for a while.

First of all, I wanted to get rid of 'Archive' button misbehavior: under Icaros Desktop, the 'Archive' button in listers created either a LHA, or a ZIP, or a TAR archive if you selected two or more files and pressed it with the left, right or center mouse button. Why 'two' and not 'one' or more? That's because of the way Magellan seems to handle the operation. According to DOpus 5 documentations, in fact, if I set an action like this:

lha a {ou-}.lha {O}

I should get an archive named like the first selected file (which wouldn't be unselected), with the original extension replaced by .lha, which would include all selected files (that would be immediately selected afterwards). So, if we select these files:

one.txt
two.doc
three.jpg

and click the 'LHA Archive' button, I should get a 'one.lha' archive containing all three. In reality, this mechanism is somewhere broken. In fact, if I try to follow what Magellan is actually doing, I can easily discover that the command performed would be the following instead:

lha a one.lha two.doc three.jpg

In a nutshell, the first one would be 'renamed' as intended but ignored by the {O} part. Until now, I worked around this by adding a {o} that would consider the first selected file to be archived (one.txt) as well. So this command was used:

 lha a {ou-}.lha {o} {O}

which produced a command like this:

lha a one.lha one.txt two.doc three.jpg

What was the problem, then? For some reason, you can't use {O} instead of {o} when you have a single selected file to consider. Magellan for some unknown reason creates its temporary script in T: but does not execute it. Why? Well, I simply can't understand it. The solution, by the way, has been easier that I could think and it's been replacing the 'naming' part with a file requester that would ask the user for the name of the resulting archive. Something like:

 lha a {RF} {O}

which now produces a result like this:


Just enter a name for the archive, and it will be created, even if you have selected a single file or a single directory to be 'frozen'. This way, without any apparent logic, capital {O} flawlessly works with single file selections. 

Thursday, August 8, 2019

Summer works on Icaros Desktop

by on Thursday, August 08, 2019
Works on Icaros Desktop continue. I have decided to pause 64bit developments for some days, while I'm on vacation, and to work again on the usual 32bit version of the distribution. I have, for now, added some programs released or updated in july, and backported Icaros' improved launch script. The best addition so far, IMHO, is the Leu spreadsheet program from ALB42, a very promising application which may dramatically improve AROS useability for classic home duties. Leu can read and edit documents from Microsoft Excel (.xlsx), LibreOffice Calc (.ods), and some other formats. I don't know exacly how much compatibile it is, but I've opened without issues almost all the sheets I used for work, and I could even edit and save them into a different format.


Obviously, a filetype for spreadsheets has been added to Magellan as well, in order to open them with a double click. I've also added a filetype for LUA scripts, which can now be executed from Magellan.

Translate