distok/cutthecord

Archived

Fork 18

GUI compiler #68

New issue

Closed

opened 2020-07-08 10:44:24 +00:00 by KaKi87 · 3 comments

KaKi87 commented

2020-07-08 10:44:24 +00:00

Hello,

As an alternative to #62, which final purpose is to provide a user-friendly way to enable and disable plugins, I would like to suggest creating a GUI compiler, on which the user would check or uncheck plugins to add or not add then create the compiled APK automatically.

As a bonus, it would be great if the tool wouldn't be a computer software that will not be available on mobile and will require several build dependencies, but a responsive (mobile-ready) browser application which will consume an HTTP API that will compile server-side then allow the user to only download the ready-to-use APK.

If someone wants to help me figure out in detail how to make a CLI-only compilation, I volunteer to build a webapp.

Thanks

Hello, As an alternative to #62, which final purpose is to provide a user-friendly way to enable and disable plugins, I would like to suggest creating a GUI compiler, on which the user would check or uncheck plugins to add or not add then create the compiled APK automatically. As a bonus, it would be great if the tool wouldn't be a computer software that will not be available on mobile and will require several build dependencies, but a responsive (mobile-ready) browser application which will consume an HTTP API that will compile server-side then allow the user to only download the ready-to-use APK. If someone wants to help me figure out in detail how to make a CLI-only compilation, I volunteer to build a webapp. Thanks

luna commented

2020-07-08 18:14:25 +00:00

My opinions:

CTCCI exists, https://gitdab.com/distok/cutthecord/src/branch/master/ctcci
- Users can request a patchset to be added to CTCCI, which goes to F-Droid, I can't guarantee it'll be added, though.
Any server doing builds for anyone on request with any patchset should be pretty strict, to prevent abuse. And also very beefy.
- In regards to abuse: there are, currently, 28 independent patches, the total amount of patchsets is much, much higher. Any backend built for this should have strict requirements on how it does things like caching, or overall build resource usage.

My opinions: - CTCCI exists, https://gitdab.com/distok/cutthecord/src/branch/master/ctcci - Users can request a patchset to be added to CTCCI, which goes to F-Droid, I can't guarantee it'll be added, though. - Any server doing builds for anyone on request with any patchset should be pretty strict, to prevent abuse. And also very beefy. - In regards to abuse: there are, currently, 28 independent patches, the total amount of patchsets is much, much higher. Any backend built for this should have strict requirements on how it does things like caching, or overall build resource usage.

a commented

2020-07-29 23:48:46 +00:00

Owner

Luna covered most of the ground here, but I'd like to word it myself too:

There's 2 ways of going with this, either we have the user build CTC, or we have a service build CTC.

Both of these have pros and cons.

With users building things, we require user to own a compatible development space. While ideally everyone would have a computer that either runs Linux or is capable of running a Linux VM, I do think that we do need to be a bit more realistic here and accept that a significant portion of our userbase either lack the hardware or the knowledge. Those that do can use CTCCI or build manually, and get all the control they want over their builds without ever needing to ask for help from us, be knowledge, be computational power.

While the tooling could be improved to support more operating systems, I do not have a non-Linux dev environment, and sadly do not have an interest at the time to try and maintain CTCCI for more than just linux.

With there being a service like a webapp building things, well... you're going to need a lot of computational power. Each build can take upwards of a minute even on relatively fast CPUs, and with a large amount of patch options, even if you cached the artifacts and served them for identical builds, optimized builds by basing them on resulting environments of builds that have a subset of builds (which can make builds faster as apktool caches certain things), you're still looking at a potentially huge amount of power to dedicate.

This is something I may be willing to sponsor, though I'm not interested in developing this right now, and it concerns me regarding updates and also about patches that clash, patches that require a specific application order, patches that rely on each other etc.

Right now, CTC is a bit more on a middle ground than anything. There's ctcci and docs for those that want to build it themselves, and the premade sets of builds for the rest available over fdroid (and friends etc do request their own builds sometimes, which do get added).

I suppose, if the issues with webapp etc was solved, we might proceed with that.

Luna covered most of the ground here, but I'd like to word it myself too: There's 2 ways of going with this, either we have the user build CTC, or we have a service build CTC. Both of these have pros and cons. --- With users building things, we require user to own a compatible development space. While ideally everyone would have a computer that either runs Linux or is capable of running a Linux VM, I do think that we do need to be a bit more realistic here and accept that a significant portion of our userbase either lack the hardware or the knowledge. Those that do can use CTCCI or build manually, and get all the control they want over their builds without ever needing to ask for help from us, be knowledge, be computational power. While the tooling could be improved to support more operating systems, I do not have a non-Linux dev environment, and sadly do not have an interest at the time to try and maintain CTCCI for more than just linux. --- With there being a service like a webapp building things, well... you're going to need a lot of computational power. Each build can take upwards of a minute even on relatively fast CPUs, and with a large amount of patch options, even if you cached the artifacts and served them for identical builds, optimized builds by basing them on resulting environments of builds that have a subset of builds (which can make builds faster as apktool caches certain things), you're still looking at a potentially huge amount of power to dedicate. This is something I _may_ be willing to sponsor, though I'm not interested in developing this right now, and it concerns me regarding updates and also about patches that clash, patches that require a specific application order, patches that rely on each other etc. --- Right now, CTC is a bit more on a middle ground than anything. There's ctcci and docs for those that want to build it themselves, and the premade sets of builds for the rest available over fdroid (and friends etc do request their own builds sometimes, which do get added). I suppose, if the issues with webapp etc was solved, we might proceed with that.

a closed this issue

2020-07-31 12:59:02 +00:00

KaKi87 commented

2020-08-06 07:44:27 +00:00

Author

CTCCI exists

Alright, would it be possible to at least create a README.md in that folder and but a comparative table of which module is included on which package ?

Though for now I'll settle for a package which contains all modules.

Any server

Actually, I don't only volunteer to create the app but also to host it.

Any backend built for this should have strict requirements on how it does things like caching, or overall build resource usage.

Would you guide me through this ?

Since I'm not experienced at all on APK builds, the only optimization I'd implement by myself is preventing from rebuilding APKs for a combination of modules that already have been built.

I do not have a non-Linux dev environment, and sadly do not have an interest at the time to try and maintain CTCCI for more than just linux.

Even if you'd maintain CTCCI for non-Linux environments, the final objective wouldn't be reached : it will still require a computer, minimal developer skills, and won't be user-friendly.

you’re still looking at a potentially huge amount of power to dedicate

That's not an issue for me.
Plus, I won't allow more than a single simultaneous build anyway.

This is something I may be willing to sponsor, though I’m not interested in developing this right now

I don't need anyone to either sponsor it nor develop it. The only thing I need is assistance for using CTCCI.

it concerns me regarding updates

I don't start end-user projects that I wouldn't intend to keep up to date.
And it will be FLOSS anyway.

also about patches that clash, patches that require a specific application order, patches that rely on each other etc.

That will be what I'll need help for. If you can guide me through these specifications, I'll make my app behave the right way.

friends etc do request their own builds sometimes, which do get added

This this a perfect example to demonstrate the inequality I'm going to solve.

Thanks !

> CTCCI exists Alright, would it be possible to at least create a `README.md` in that folder and but a comparative table of which module is included on which package ? Though for now I'll settle for a package which contains all modules. > Any server Actually, I don't only volunteer to create the app but also to host it. > Any backend built for this should have strict requirements on how it does things like caching, or overall build resource usage. Would you guide me through this ? Since I'm not experienced at all on APK builds, the only optimization I'd implement by myself is preventing from rebuilding APKs for a combination of modules that already have been built. > I do not have a non-Linux dev environment, and sadly do not have an interest at the time to try and maintain CTCCI for more than just linux. Even if you'd maintain CTCCI for non-Linux environments, the final objective wouldn't be reached : it will still require a computer, minimal developer skills, and won't be user-friendly. > you’re still looking at a potentially huge amount of power to dedicate That's not an issue for me. Plus, I won't allow more than a single simultaneous build anyway. > This is something I may be willing to sponsor, though I’m not interested in developing this right now I don't need anyone to either sponsor it nor develop it. The only thing I need is assistance for using CTCCI. > it concerns me regarding updates I don't start end-user projects that I wouldn't intend to keep up to date. And it will be FLOSS anyway. > also about patches that clash, patches that require a specific application order, patches that rely on each other etc. That will be what I'll need help for. If you can guide me through these specifications, I'll make my app behave the right way. > friends etc do request their own builds sometimes, which do get added This this a perfect example to demonstrate the inequality I'm going to solve. Thanks !

This repo is archived. You cannot comment on issues.