simple CLI #1

Closed
opened 4 years ago by Kirafi · 12 comments
Kirafi commented 4 years ago

Create a new project interactively

fxsdk new <name>

Description

Create a project ready to build with an autogenerated tree structure in folder.

The Makefile is generic.

Tree Structure

ressources
├── font.png
├── icon.png
└── ...
build.fx # and/or build.gc
└── ...
include
└── ...
src
├── main.c
└── ...
Makefile

Example

% fxsdk new tetris-delux
Creating a new project in folder 'tetris-delux'.

Full project name ?
> Tetris Delux
Short project name (full uppercase, no-space and max 8 letters) ?
> TETRISDX
Build for ?
- [0] fx-9860G II (Graph 35+E/Graph 75+E)
- [1] fx-CG 50 (Graph 90+E)
- [2] both
> 0

Tetris Delux successfully created.

Build project

fxsdk build [-s]

Option

  • -s to automatically send the g1a or g3a to a connected calculator (see below).

Decription

Simple make all-(fx|cg) wrapper, for more standard command.

Avoid to precise FX or CG, according to the word used in the new project command.

Connect a calculator

Usage fxsdk connect

Description

Connect a calculator to debug. Using p7 ?

Send to a connected calculator

Usage fxsdk send

Description

Send the g1a or g3a to a connected calculator.

Simple p7 send -f# <name>.g(1|3)a wrapper.

# Create a new project interactively `fxsdk new <name>` **Description** Create a project ready to build with an autogenerated tree structure in <name> folder. The Makefile is generic. **Tree Structure** ``` ressources ├── font.png ├── icon.png └── ... build.fx # and/or build.gc └── ... include └── ... src ├── main.c └── ... Makefile ``` **Example** ``` % fxsdk new tetris-delux Creating a new project in folder 'tetris-delux'. Full project name ? > Tetris Delux Short project name (full uppercase, no-space and max 8 letters) ? > TETRISDX Build for ? - [0] fx-9860G II (Graph 35+E/Graph 75+E) - [1] fx-CG 50 (Graph 90+E) - [2] both > 0 Tetris Delux successfully created. ``` # Build project `fxsdk build [-s]` **Option** - `-s` to automatically send the g1a or g3a to a connected calculator (see below). **Decription** Simple `make all-(fx|cg)` wrapper, for more standard command. Avoid to precise FX or CG, according to the word used in the new project command. # Connect a calculator **Usage** `fxsdk connect` **Description** Connect a calculator to debug. Using [p7](https://www.planet-casio.com/Fr/forums/topic14487-6--GNU-Linux--P7,-pour-des-transferts-a-repasser.html) ? # Send to a connected calculator **Usage** `fxsdk send` **Description** Send the g1a or g3a to a connected calculator. Simple `p7 send -f# <name>.g(1|3)a` wrapper.

Excellent! I've started working on this as a shell script (much more suited than C for this task).

The main thing I was not happy with until now was handling dual-platform projects (ie. build for both fx9860g and fxcg50). We discussed decent options, but this felt too rigid to me.

So I tried to refine this with a smarter behavior. Here's the idea:

  • fxsdk build-fx creates the build.fx folder and compiles for fx9860g
  • fxsdk build-cg creates the build.cg folder and compiles for fxcg50
  • fxsdk build compiles in all existing build directories

This way, you can change the platform whenever you want by just compiling in a new folder. If you start fxsdk build but no build folder is present, you are interactively prompted for a platform.

When sending the file, you can use fxsdk send-fx or fxsdk send-cg to make explicit which method to use, but if only one build directory exists then you can type fxsdk send and the associated method will be selected.

How does that sound ? 😀

We also need a configuration file somewhere to store details such as the name and internal name of the add-in, the icon, and the like. I think it will take the form of a list of assignments in the syntax of Bash, so that it can be loaded and edited easily.

Excellent! I've started working on this as a shell script (much more suited than C for this task). The main thing I was not happy with until now was handling dual-platform projects (ie. build for both fx9860g and fxcg50). We discussed decent options, but this felt too rigid to me. So I tried to refine this with a smarter behavior. Here's the idea: * `fxsdk build-fx` creates the `build.fx` folder and compiles for fx9860g * `fxsdk build-cg` creates the `build.cg` folder and compiles for fxcg50 * `fxsdk build` compiles in all existing build directories This way, you can change the platform whenever you want by just compiling in a new folder. If you start `fxsdk build` but no build folder is present, you are interactively prompted for a platform. When sending the file, you can use `fxsdk send-fx` or `fxsdk send-cg` to make explicit which method to use, but if only one build directory exists then you can type `fxsdk send` and the associated method will be selected. How does that sound ? :grinning: We also need a configuration file somewhere to store details such as the name and internal name of the add-in, the icon, and the like. I think it will take the form of a list of assignments in the syntax of Bash, so that it can be loaded and edited easily.
Poster

build

So you want to remove this in the interactive command new ?

Build for ?
- [0] fx-9860G II (Graph 35+E/Graph 75+E)
- [1] fx-CG 50 (Graph 90+E)
- [2] both

Because the project can build nativelly for both (if we defined the draw functions for both in our program) ?

It's seems correct to me 👍 .

configuration

As I said in previous Issue on gitlab (I forgot to mention here), usually a configuration file is in YAML syntax (or JSON, but YAML is better human readable).

The file can look like this

name:
  full: "Tetris Delux"
  short: "TETRISDX"
version: v1.1.0
...

I think, because the images of fx and cg are always different, we can have 2 ressources folder :

  • ressources-fx
  • ressources-cg

At root directly or in sub folder of ressources folder.

And because the icon is unique, I think we can cut out from the configuration file.

**build** So you want to remove this in the interactive command `new` ? ``` Build for ? - [0] fx-9860G II (Graph 35+E/Graph 75+E) - [1] fx-CG 50 (Graph 90+E) - [2] both ``` Because the project can build nativelly for both (if we defined the draw functions for both in our program) ? It's seems correct to me :thumbsup: . **configuration** As I said in previous Issue on gitlab (I forgot to mention here), usually a configuration file is in YAML syntax (or JSON, but YAML is better human readable). The file can look like this ``` name: full: "Tetris Delux" short: "TETRISDX" version: v1.1.0 ... ``` I think, because the images of fx and cg are always different, we can have 2 ressources folder : - ressources-fx - ressources-cg At root directly or in sub folder of ressources folder. And because the icon is unique, I think we can cut out from the configuration file.

I can either fully remove the platform selection, or offer to create initial empty build directories to avoid some interaction when fxsdk build is invoked for the first time. Both are fine with me.

Having a configuration file in YAML is nice, but parsing it is a nightmare. I think this should be enough:

name="Tetris Delux"
internal="@TETRISD"
version="git"

And so on. (Note the git versioning scheme, which would place a commit number or tag name in the version field.)

Yes, you need two resource folders, also fxconv needs to be aware of the target platform to properly do its job. But I don't want to enforce specific file names for icons, especially since :

  • There are two of them on fx-CG 50, and no "trivial" way to name them;
  • The image format (thus the extension) is not fixed;
  • You might not want to place them in the resource folders.
I can either fully remove the platform selection, or offer to create initial empty build directories to avoid some interaction when `fxsdk build` is invoked for the first time. Both are fine with me. Having a configuration file in YAML is nice, but parsing it is a nightmare. I think this should be enough: ```bash name="Tetris Delux" internal="@TETRISD" version="git" ``` And so on. (Note the `git` versioning scheme, which would place a commit number or tag name in the version field.) Yes, you need two resource folders, also `fxconv` needs to be aware of the target platform to properly do its job. But I don't want to enforce specific file names for icons, especially since : * There are two of them on fx-CG 50, and no "trivial" way to name them; * The image format (thus the extension) is not fixed; * You might not want to place them in the resource folders.
Poster

configuration

I think remove totally is better, because I imagine a case of someone create a fx project only, but latter, he want to extend to cg.

Okay for configuration in simple text file, KISS keep it simple, stupid 👍 .

icon extension

I am sure you can build the generic Makefile to consider all icon extension format 😛 If there is only .png .bmp.

And if gint only allow .png, why someone create an icon with other extension ? So we can maybe force png format ?

icon location

With 2 ressources folder, I had imagined 1 icon.png on each => fix name problem.

To me it's not weird to have icon in ressources folder (in androidstudio it's like this).

But the idea of "in ressources folder there should only has images used in program" is interesting... So icon should be in root folder, with name icon-fx.png ?

**configuration** I think remove totally is better, because I imagine a case of someone create a fx project only, but latter, he want to extend to cg. Okay for configuration in simple text file, KISS *keep it simple, stupid* :+1: . **icon extension** I am sure you can build the generic Makefile to consider all icon extension format :stuck_out_tongue: If there is only `.png` `.bmp`. And if gint only allow `.png`, why someone create an icon with other extension ? So we can maybe force png format ? **icon location** With 2 ressources folder, I had imagined 1 `icon.png` on each => fix name problem. To me it's not weird to have icon in ressources folder (in androidstudio it's like this). But the idea of "in ressources folder there should only has images used in program" is interesting... So icon should be in root folder, with name `icon-fx.png` ?

Ah well, I was a bit fast, fxg1a only supports png. But fxconv is written in Python, so it supports pretty much every format here.

You may not know it, but two icons must be provided for a fx-CG 50 add-in: selected and unselected. On fx-9860G, the icon is just inverted when it is selected, but this is no longer the case on color screens.

I'd prefer having resources-fx/icon.png and resources-cg/icon-uns.png, resources-cg/icon-sel.png as default locations, and leave a parameter in the config file. It has no complexity cost, no setup cost for beginners, and it won't get in the way of people who put icons outside the resource folder.

By the way, the resource folder is also likely to include every font used by the add-in, as well as binary data files such as maps or whatever static data the application uses. This way of managing resources is much cleaner than having weird constant arrays in the code.

Ah well, I was a bit fast, `fxg1a` only supports png. But `fxconv` is written in Python, so it supports [pretty much every format here](https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html). You may not know it, but two icons must be provided for a fx-CG 50 add-in: selected and unselected. On fx-9860G, the icon is just inverted when it is selected, but this is no longer the case on color screens. I'd prefer having `resources-fx/icon.png` and `resources-cg/icon-uns.png`, `resources-cg/icon-sel.png` as default locations, and leave a parameter in the config file. It has no complexity cost, no setup cost for beginners, and it won't get in the way of people who put icons outside the resource folder. By the way, the resource folder is also likely to include every font used by the add-in, as well as binary data files such as maps or whatever static data the application uses. This way of managing resources is much cleaner than having weird constant arrays in the code.
Poster

Oooh okay, I didn't noticed now we can use other format than .png for images in ressources folder 😊 .

Okay 2 icons for one app, it complicates things...

So it's seems fair to include icon(s) path in configuration file.

I agree with the idea of putting default location in ressources folder 👍 .

Sure ressources isn't only images. The structure of this folder is up to the developper like

ressources-fx
├── icon.png
|
├── font
|   ├── font_large.png
|   └── font_small.png
|
├── sprites
|   ├── overworld
|   |   ├── house.png
|   |   └── sea.png
|   |
|   └── weapons
|   |   ├── sword.png
|   |   └── shield.png
|   |
|   └── ...
|
├── maps
|   ├── road_101.map
|   └── road_102.map
|
└── ...
Oooh okay, I didn't noticed now we can use other format than `.png` for images in ressources folder :blush: . Okay 2 icons for one app, it complicates things... So it's seems fair to include icon(s) path in configuration file. I agree with the idea of putting default location in ressources folder :+1: . Sure ressources isn't only images. The structure of this folder is up to the developper like ``` ressources-fx ├── icon.png | ├── font | ├── font_large.png | └── font_small.png | ├── sprites | ├── overworld | | ├── house.png | | └── sea.png | | | └── weapons | | ├── sword.png | | └── shield.png | | | └── ... | ├── maps | ├── road_101.map | └── road_102.map | └── ... ```
Lephenixnoir self-assigned this 4 years ago
Poster

Work in progress 😄 ?

Work in progress :smile: ?

I'm definitely posting a beta version of this before the end of the week. This has waited long enough.

I'm definitely posting a beta version of this before the end of the week. This has waited long enough.

The commit above introduce the very basics. You can interactively create a project (no command-line arguments supported yet):

% fxsdk new fxsdk-empty
Creating a new project in folder 'fxsdk-empty'.

Full project name ? (at most 8 characters)
> Empty
Internal name ? ('@' followed by at most 7 uppercase letters)
> @EMPTY

Your project 'Empty' has been created.

Type 'fxsdk build-fx' or 'fxsdk build-cg' to compile the program.

You get a tree like this, with the fxSDK's default icons. Images are located in assets-*/img/ and fonts in assets-*/fonts. Note that there are Makefile rules to build fonts but they won't work yet as you need to specify some metadata. I'll think about how to do it properly;

.
├── assets-cg
│   ├── icon-cg-sel.png
│   └── icon-cg-uns.png
├── assets-fx
│   └── icon-fx.png
├── Makefile
├── project.cfg
└── src
    └── main.c

The project configuration file can be edited at will once it is created (the fxSDK will not try to modify it ever again):

#---
# fxSDK project configuration file for Empty
#---

# Project name, should be at most 8 bytes long.
NAME = Empty
# Internal name, should be '@' followed by at most 7 uppercase letters.
INTERNAL = @EMPTY

# fx-9860G icon location
ICON_FX = assets-fx/icon-fx.png
# fx-CG 50 icon locations
ICON_CG_UNS = assets-cg/icon-cg-uns.png
ICON_CG_SEL = assets-cg/icon-cg-sel.png

# Additional compile flags
CFLAGS = -std=c11 -Os

You can then make the example program which prints a string on-screen. fx-CG 50 can run into trouble because the display API is not totally complete yet. gint has to keep up for that, or you can build with libfxcg.

I will add trivial commands such as build, build-fx, build-cg, install-fx soon. Installing on fx-CG 50 and the Graph 35+E II is tricky because we have to mount the machine. Probably some user configuration is required.

The commit above introduce the very basics. You can interactively create a project (no command-line arguments supported yet): ```sh % fxsdk new fxsdk-empty Creating a new project in folder 'fxsdk-empty'. Full project name ? (at most 8 characters) > Empty Internal name ? ('@' followed by at most 7 uppercase letters) > @EMPTY Your project 'Empty' has been created. Type 'fxsdk build-fx' or 'fxsdk build-cg' to compile the program. ``` You get a tree like this, with the fxSDK's default icons. Images are located in `assets-*/img/` and fonts in `assets-*/fonts`. Note that there are Makefile rules to build fonts but they won't work yet as you need to specify some metadata. I'll think about how to do it properly; ``` . ├── assets-cg │   ├── icon-cg-sel.png │   └── icon-cg-uns.png ├── assets-fx │   └── icon-fx.png ├── Makefile ├── project.cfg └── src └── main.c ``` The project configuration file can be edited at will once it is created (the fxSDK will not try to modify it ever again): ```makefile #--- # fxSDK project configuration file for Empty #--- # Project name, should be at most 8 bytes long. NAME = Empty # Internal name, should be '@' followed by at most 7 uppercase letters. INTERNAL = @EMPTY # fx-9860G icon location ICON_FX = assets-fx/icon-fx.png # fx-CG 50 icon locations ICON_CG_UNS = assets-cg/icon-cg-uns.png ICON_CG_SEL = assets-cg/icon-cg-sel.png # Additional compile flags CFLAGS = -std=c11 -Os ``` You can then `make` the example program which prints a string on-screen. fx-CG 50 can run into trouble because the display API is not totally complete yet. gint has to keep up for that, or you can build with libfxcg. I will add trivial commands such as `build`, `build-fx`, `build-cg`, `install-fx` soon. Installing on fx-CG 50 and the Graph 35+E II is tricky because we have to mount the machine. Probably some user configuration is required.

This should start looking good. There's still work to do on asset conversion, in particular where to put the metadata. fxconv is build so that we can do this from Python. The question and when and where...

Let me know if this looks good to you. ^^

This should start looking good. There's still work to do on asset conversion, in particular where to put the metadata. fxconv is build so that we can do this from Python. The question and when and where... Let me know if this looks good to you. ^^
Poster

Good job, it seems correct for now 😄 . I will test it when I have time for Casio development.

Good job, it seems correct for now :smile: . I will test it when I have time for Casio development.

Since the CLI has been rolling for quite a while now, and decent success, I'm closing this issue. Feel free to reopen or open a new issue if something's amiss.

Since the CLI has been rolling for quite a while now, and decent success, I'm closing this issue. Feel free to reopen or open a new issue if something's amiss.
Lephenixnoir closed this issue 3 years ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Lephenixnoir/fxsdk#1
Loading…
There is no content yet.