Splitting project architecture

[toxinu]

Do you think that we need to split a little more this project ?
I have in my head something a little more like git-extras for example.

Create real man and a brand new Makefile for cleaner installation.

I think love-release will be bigger every day and we need something more modular.

[josefnpat]

I second the makefile and man page. I think while it may not be popular now, could very well be an awesome tool for developers to install on their *nix systems.

[pablomayobre]

Third this! plus I would also like to exclude/ignore some files for some OS (For example compressed textures that work on Android are ignored in the rest of the OSs). This could be done with a configuration file and using a temporary folder (a copy of the game folder) and then deleting the unneeded files (that are in the configuration file) before zipping

[MisterDA]

Making an option to exclude files was pne of my greatest wills about this. But I never really understood how zip was understanding filepaths (it's quite special) and I did not make a lot of research about it. Of course, this would be an usefull improvement. For now, you can't really exclude files, but you van choose which ones to include.

Splitting all of this is a great idea too. I'm thinking about this, but I can't really work on it right now.

[josefnpat]

For HDF I did the following;

I created a profile for each deployable OS/Device (e.g. desktop(win,mac,lin) | android tablets | ouya ), and they contained specific defined strings. One such string was:

For the OUYA profile: render_resource_etc = ".ect1"
For the Desktop profile: render_resource_etc = ".png"

Then each profile would use a different stored zip command:

zip --filesync -r --exclude=*.mjpeg* --exclude=*.high* --exclude=*.medium* "../android/game.love" *

So basically I deployed both the .ect1 and the .png, and in the code I did:

x = love.graphics.newImage("potatobartender."..render_quality.."..render_resource_etc

Not sure if this helps, but maybe my workflow will spark a few ideas.

The best thing to do I suppose would be to create asset folders per profile:

src/assets/profile_ouya/dog.ect1
src/assets/profile_desktop/dog.png
src/assets/shared_potato.png
src/main.lua

and when you zip, --exclude every src/assets/profile_* that isn't the current system.

[pablomayobre]

Yeah! Exactly that... My code (in LÖVE) already handles things like that but all the files are still there... As I said before, maybe this can be accomplished with a file that contains something like the following:

-Android
    assets/desktop
-MacOSX
    assets/android
-Windows
    assets/android
-Linux
    assets/android

So when the script reads this file it will ignore the appropriate directories for the OS... When you make a .deb then the zip command is called with --exclude "assets/android/" but when you make an .apk it is called with --exclude "assets/desktop/" instead

This also means that you need to generate a .love file for each OS but we can work it out somehow (like using the same .love for Linux, Windows and Mac in the example above) .

This file could also handle the configuration for each OS (for example the Activity name in android and so... Maybe even override the conf.lua settings that are needed right now)

[MisterDA]

Hi everyone !
I have begin to split everything. Now there is a main love-release script that sources the others scripts if you ask it.

It's nice, because you can see which script runs for what system. They are all independant, you cannot create two executables for two different plateforms at the same time, this way we don't mix options about icons and maintainers and everything.
The one thing I'm disappointed about is that I have to declare the options the subscripts will be using in the main script, or they would be parsed as files... But I find the way it's done here is pretty fine.

I have also made an install script, but it only run as root.
Next things will be...

• an exclude option,
• maybe PKGBUILD,
• support for icons in Debian pkg, Android and OUYA,
• an INI parser to add a configuration (thinking of this one), see this Gist for possible config,
• and I'm getting trouble to properly parse OS X Info.plist, so it is still completely rewritten.

The script might need to be heavily tested, please test and tell me if you have suggestions or found a bug.
I don't know enough about Makefiles to make one by myself, and it could be complex to turn love-release into a full set of Makefiles.

About profiles, my first idea was to make love-release as easy as possible for the end user. I didn't want to force him to use a specific naming convention, like assets/profile or even an icon directory. So it's a bit difficult to exclude the icons that belong to another system it the scheme I've made.
I know it's a good thing though, and if you feel like we should find a naming scheme, or a profile, or whatever, let's discuss that.

[josefnpat]

I tested this on my project, and it looks like it runs well!

~/repos/love-release/love-release.sh -mwl -n "Test Project" 
~/repos/slg09x/wat♠ tree releases/
releases/
└── 0.9.1
    ├── Test Project-macosx-x64.zip
    ├── Test Project-win32.zip
    └── Test Project-win64.zip

I will note that it looks like it's ignoring my -l flag. Do you want a ticket on it, or is this ok?

[MisterDA]

Well... Now that is is modular, only one system can be generated at a time... So it just create executable for the first and skips the others. If you are on the modules branch, it should not even create zip pkg for osx and windows in the same time...

[josefnpat]

Ah! Maybe they're left over from the previous tests I ran. I will test from a clean environment.

Perhaps now that "modules" are being introduced, it might behove us to batch the builds depending on the provided flags? -lwmd should be a totally legit input!

[MisterDA]

Yes, but for example OS X and Windows use the same --icon option, OS X, Debian and android use also the same --maintainer-name. Should it be prefixed ? Like --win-icon, --osx-icon ?
With a config file, there is no problem to generate multiple builds, but passing from the CLI is a bit more tricky.

[josefnpat]

I see what you mean. I would vote without a config file, it's only one build at a time; but that ought to be clearly documented.

[MisterDA]

On the other hand, the only options that are shared are:

• --package-version, it could be the same for all packages
• --package-name, the same on OS X and Android (e.g. freddiemercury) but different on Debian (e.g. `Freddie Mercury)
• --icon, different for all

What I mean is for the version we could just assume it will be the same, for the package name I may be able to detect if it is in lowercase-style or in full name style, and for the icons it could be very easy if the user pointed to a location like --icon src/assets and there was different profiles inside. But we have to agree on the naming convention. This is an example (see #3 for icons).

src/assets
├── android
│   └── 42x42
│       └── ic_launcher.png
├── debian
│   ├── 16x16
│   │   └── game.png
│   └── 32x32
│       └── game.png
├── macosx
│   └── game.icns
├── ouya
│   ├── ic_launcher.png
│   └── ouya_icon.png
└── windows
    └── game.ico

[pablomayobre]

what about .svg icons and an ouya_icon.png and that's it (as discussed in #3 )? Wouldn't it be easier with this setup? Of course leaving the option of selecting your own icons by specifying the path to them

[MisterDA]

Yeah, but same way that with the --filesync option, it would be stupid to regenerate every time the icons from an svg file... And we can't force the user to provide only a SVG file.
Right now I'm working on the configuration and on the -lwmd should be a totally legit input! problem, I'll get to this quick, I hope.

EDIT: Configuration works ! Will push the changes after full testing. ☕

[josefnpat]

🍇 job!

[MisterDA]

About -lwmd should be a totally legit input!, I think prefixed options are the best solution. It is stupid to make only one build at a time.
I added a -x option to exclude files.

Maybe it is time to merge changes in master branch ? With Lundum Dare start, love-release might be useful for someone out there...