sc-make

SC-MAKE

Reusable git, make and golang templates for projects.

Docs: https://gedw99.github.io/sc-make/

Just like you need a golang compiler to compile golang, you need Makefiles, Templates and binaries to work on golang projects.

All you need is this in your makefile:

MAKE_FSPATH=./../../assets/.sc-make/make
include $(MAKE_FSPATH)/help.mk
include $(MAKE_FSPATH)/caddy.mk
include $(MAKE_FSPATH)/env.mk
include $(MAKE_FSPATH)/fly.mk
include $(MAKE_FSPATH)/git.mk
include $(MAKE_FSPATH)/go.mk
include $(MAKE_FSPATH)/gio.mk
include $(MAKE_FSPATH)/git.mk
include $(MAKE_FSPATH)/github.mk
include $(MAKE_FSPATH)/nats.mk
include $(MAKE_FSPATH)/task.mk
include $(MAKE_FSPATH)/vscode.mk

You can pick and choose what things you need.

Then in your makefile, prefix all maefile tagets with "this". Its just a simple way of ensuring there are no make namespace clashes.

Install

if you are a User ( i mean a developer but not a core developer ), then you can use the web site. This will call our go build server, pull this git repo, build and return a binary baaed on your OS and ISA. you will get the full transparency log so that you can be sure this binary is tamper proof!

If you are a core developer you will need to setup a development environment.

To install go, ssh, git and make on IOS and Android we use alpine linux emulation that is bundled in the uroot bootstrapper ishell:

''' apk add --update --no-cache go vim git make musl-dev curl '''

To installl on Web: ''' todo: add instructions here... '''

To install on Desktop: ''' todo: add lonk to Recursive go build server ... '''

We dont have full CI and Release working yet.

We also need to add self updating and alerting for when new versions are avaialble.

• this will be done each time you use the tool.

Build

Installs to the GOAPTH/bin.

make bin-install

This will build the binary and deploy it to the GO BIN, so its on your path ( for example: /Users/apple/workspace/go/bin )

Deps

When you do a ''' make dep-caddy ''' thee is no check for if its already installed.

TODO: make each dep.mk check for it being installed and the version we want.

Test Harness

In the test-harness folder are example git projects where you can try different things out.

Examples

At https://github.com/gedw99/sc-make-examples are more expansive examples.

They might not be up to date.

They assume you have installed sc-make already on your path.

SC Editor

The approahc we take is that an Editor also needs to do the same thngs on their projects.

But instead of usng makefiles we use golang wrapper commands to do things, allng with NATS to help it along. NATS provides the basic way for the Editor to talk to the Files system as well as to run binaries on the file system.

We use go-task as a replacement for makefile, in order to allo the Editor to configure certain things. How that is fully done is not working out yet. We probably need a Manifest file for versioningwhat binaries are used.

We use build tags so turn ON or Off the makefile aspects.

SC Editors dont need the makefile aspects, because the makefiles is for internal development teams.

SC Tasks is based on go-task to provide a way for Editors that are not coders to have a similar makefile feasture set, but can manage it from the Editor or CLI.

Commands

The architecture style is that commands are accessed via NATS.

Commands expose stdin / stdout / stderror, and so can be called like a Serverless Functions architecture. The Editor sends in an event and NATS dispatches that to a Consumer. The Consumer is a worker on the file system. SO its like classic CGI where its all just a file system call, and the binary is started up, and NATS sends the event to it. If the binary is not there on the File System, NATS will pull it at the right version. This is why its a Servrless style of design.

##Setup / Install**

Before you can do anything there are certain binaries and settings you need on your Laptop or Server.

You already have sc-make, but you also need NATS, Caddy, and some other things installed.

These are OS level, and so we install these globally.

They are NOT versiongn, in that you cant have different versions of each binary on your laptop or Server.

It can also manage updates and migrations.

Project

This is all based on wrapper for git and git-lfs

The init system is really just like the git workflwo pattern and is under the hood using git.

Git and git-lfs allow a Designer to have Code and Assets ( images ) all in a single project.

• Creates a New Project
  • Just creates a new git project
• Get an existing Project
  • just does a git clone.
• Copy a ProJect
  • Just forks a git project from a git server, and then just does a Get an Existing Project.

Bootstrap

This uses the NATS registry that was installed during the Install phase.

It pulls binaries that your Project says that it needs in its manifest.

• For any new Project there are things that need to be done.
• Pulling binaries globally. A Project will be dependent on a version of a binary, so ALL binaries are versioned, so that you can store many binary versions in a file cache.
• We maintain a registry of binaries. Will use NATS KV and NATS Object store i think.
  • Just need to add this sc tasks as a first class citizen.
• setting up git and git-lfs
  • These are probably NOT versioned because they are so crucial at the OS level.