When using directories, the docker images will start
generaties files inside these directories, with root
privileges.
These files cannot be removed by the user, even though
he owned the directory.
So I decided to use volumes instead, since this alleviate
the issue.
I'll add a volume management API letter. For the time
being, you'll have to rely on docker-compose volume
commands to manage them.
Signed-off-by: Myy Miouyouyou <myy@miouyouyou.fr>
This retarded editor will delete spaces at the end of
Markdown lines EVEN WHEN ASKED TO NEVER DO IT !
Two spaces to create a line-break in Markdown is
PART OF THE SYNTAX !
So, I'm now switching to Code for Markdown.
Signed-off-by: Myy Miouyouyou <myy@miouyouyou.fr>
There's still a lot to do before it becomes really user-friendly,
but at least, this thing won't spout weird Debug messages for
nothing at the moment.
Also, you can now specify the execution mode using '--mode='
The DESIGN.md now looks more like a "First module guide"
but some parts are now missing...
I'll try to fix that when possible.
Signed-off-by: Myy Miouyouyou <myy@miouyouyou.fr>
Even though the packaging script is still not created, this
helps understand which files are used by the packager.
I still feel that I omitted a few things here and there.
But the main parts are present !
Signed-off-by: Myy Miouyouyou <myy@miouyouyou.fr>
In order to package the modules correctly, a package-manager specific
directory architecture has been put in place.
The whole idea to have something like that, inside the module
directory :
* armbian
* DEPS : Global installation dependencies
* DEPS.build : Dependencies only required to build the actual
module project
* BUILD.sh : The script run at the module root directory to
build the whole module.
* POSTINST.sh : Global Post-installation script
* all-archs/
* cli/
* DEPS : Cli specific dependencies
* module/ : Module files copied on the harddrive...
* gui/
* POSTINST.sh : GUI specific Post-installation script
* DEPS : GUI specific dependencies
* module/ : Module files copied on the harddrive...
* armv7/ : ARMv7 specific modules
* aarch64 : ARMv8 64 bits specific modules
* aarch64.rockchip : ARMv8 64 bits specific modules for Rockchip
First, note that the architectures directories are not required
per-se. You can go with only "all-archs". Only create an "armv7"
directory if it makes sense for you to have a Armv7 specific
module.
This is generally the case if the module needs to be built for
a specific architecture.
Second, while the files (DEPS, POSTINST.sh, ...) are concatenated,
each architecture is independant, and the packaging script WILL NOT
OVERLAY THEM.
Meaning that the module files need to copied over and over, in each
invidiual architecture directory.
Signed-off-by: Myy Miouyouyou <myy@miouyouyou.fr>
In order to package the modules correctly, a package-manager specific
directory architecture has been put in place.
The whole idea to have something like that, inside the module
directory :
* armbian
* DEPS : Global installation dependencies
* DEPS.build : Dependencies only required to build the actual
module project
* BUILD.sh : The script run at the module root directory to
build the whole module.
* POSTINST.sh : Global Post-installation script
* all-archs/
* cli/
* DEPS : Cli specific dependencies
* module/ : Module files copied on the harddrive...
* gui/
* POSTINST.sh : GUI specific Post-installation script
* DEPS : GUI specific dependencies
* module/ : Module files copied on the harddrive...
* armv7/ : ARMv7 specific modules
* aarch64 : ARMv8 64 bits specific modules
* aarch64.rockchip : ARMv8 64 bits specific modules for Rockchip
First, note that the architectures directories are not required
per-se. You can go with only "all-archs". Only create an "armv7"
directory if it makes sense for you to have a Armv7 specific
module.
This is generally the case if the module needs to be built for
a specific architecture.
Second, while the files (DEPS, POSTINST.sh, ...) are concatenated,
each architecture is independant, and the packaging script WILL NOT
OVERLAY THEM.
Meaning that the module files need to copied over and over, in each
invidiual architecture directory.
Signed-off-by: Myy Miouyouyou <myy@miouyouyou.fr>
The configuraiton now works by default.
Such progress...
It also provides a nginx installation, so that the user
can just go on its port 80 and check for the nice
message.
Signed-off-by: Myy Miouyouyou <myy@miouyouyou.fr>
A lot of things changed.
Now the only files necessary are :
* module_name / DESC
* module_name / cli / module
For additional modes, you can add :
* module_name / gui / module
* module_name / tui / module
And that should do the trick.
All the 'armbian' things are being moved to the packaging directory
architecture, which will come with the next update.
Signed-off-by: Myy Miouyouyou <myy@miouyouyou.fr>
There's still a lot of things I'll have to figure out here.
Currently, the whole directory is mixed bag of everything,
with packaging, execution, different modes being mixed
together into one folder.
I'm trying to separate packaging from execution, while
also separating different architectures.
Then I'll have to script the packaging nicely and test
the whole thing once installed.
The final idea is that, you'll need to have some kind
of "build" phase for any module, where you put the
files in the right folders.
I'll try to keep the number of folders as low as possible,
but still, the build phase seems unavoidable, in order to have
a clean source directory.
For simple modules, that will just mean that you'll basically code
inside the build directories, just like it's being done now.
For complex modules, that will mean the addition of a build phase in
your Makefile, CMakeFiles, meson, gradle, whatever... in order to
generate all the folders for different architectures.
Then the packaging system will just package each folder as
module M for architecture A.
This allow people using compiled languages to provide proper
executables for each architecture, obviously.
This also makes things normal and simpler in terms of sources
management.
Signed-off-by: Myy Miouyouyou <myy@miouyouyou.fr>
