C'est clair, surtout qu'Amos était super simple pour coder, faut pas lacher

Message édité par : artblink / 17-04-2016 22:57

Non !!! je ne lâche pas.

Je fais des améliorations pour le bien du produit.
La bibliothèque est déjà bien fonctionnelle mais sans réduction à l'exécutable et avec encore quelques bugs..

Hello

Je vois 2 sujets:

1) Comment réduire la taille de la amos lib

2) Comment compiler n sources (1 par fonction)

Pour le 2) je proposerai une technique de bourrin : faire un (disons) basic.c qui contiendrais juste l'inclusion des 28 fonctions de basic

#include "fonction1.c"

#include "fonction2.c"

#include "fonction3.c"

[...]

#include "fonction28.c"

Idem pour tout les autres répertoires

Puis dans ton makefile juste compiler basic.c  screen.c text.c music.c etc...

Bon ça tuera un peu l'avantage du make (puisque une seule modif de (disons) basic/function3 entrainera une recompilation de tout basic) mais ça y gagnera en clarté

Pour le 1) si ça devient une .library partagée alors ça devient moins crucial...

Si tu arrive à faire un binaire non strippé avec ton amos.a tu peut lui faire subir mon objDumpFunctions (sur aminet) et ainsi voir quelles fonctions sont les plus obèses

Attention: l'optimisation -O3 fais grossir les executables

Alain

Merci Alain !!!

C'est une superbe idée. je vais faire des testes de compilation comme tu le proposes (cela ne me fait pas peur !!!).
Pour la re-compilation si une modif. est faite et que la recompilation complète doit être faite, cela n'incombe que moi et ça c'est pas grave !!!

Au final il y aura une LibAmOS.a a mettre dans le SDK qui permettra au utilisateur de programmer sous AmOs4.

... Continuation et validation de l'optimisation de la version "beta" de l'AmOS4 ... vole vole vole ...

@Sharynn

@alex: pourri ton truc, ça m'aide pas a gagner au loto.... alors l'euromillions 

@Sharynn: