thetredev / gmakec Goto Github PK

View Code? Open in Web Editor NEW

0.0 0.0 0.0 85 KB

License: MIT License

Go 96.82% Shell 3.18%

gmakec's Introduction

Hi!

I'm Timo, an IT systems & software enthusiast from Germany with a never ending cup of curiosity.

About me

🏫 Graduated from Reutlingen University with a Bachelor of Science
💼 Currently working as IT Manager R&D at Corscience GmbH & Co. KG helping the R&D department get things done outside of their realm of responsibilities like CI/CD and infrastructure work
❤️ I love writing code, especially Python and Go
☁️ Passionate about Linux, DevOps and container technologies
💬 Got questions? Ask!

Experience

Having fun! - when I have fun doing something I'm much more into it and can be much more efficient. I make sure I never forget that.
Software development: mostly Python and Go. C/C++ not so much, but I can get around. I'm curious about new stuff coming out and always willing to learn other languages and/or different ways to go about developing software.
Software deployment: GitLab CI/CD, GitHub workflows, packaging software (deb, rpm, ...)
DevOps - to a point:
- Docker/Podman: building images, running containers, Compose deployments, networking, you name it
- Kubernetes: Setting up bare metal clusters using k0s, Helm, ArgoCD. I'm more Dev than Ops, so RBAC is still on my TODO list :)

In that order.

Side Projects

xdeb-install - Automation wrapper for the xdeb utility with its own ecosystem behind it. See https://github.com/xdeb-org
steamcmd - Sane SteamCMD docker images
Ultimate Deathmatch - Source.Python deathmatch plugin for Counter-Strike: Source and Counter-Strike: Global Offensive
FlashFun - Source.Python plugin for Counter-Strike: Source and Counter-Strike: Global Offensive where flashbang grenades are your primary weapons
Shelly - Python command line parser, decorator style
CppArgParse - C++ command line parsing made simple

Other public repositories on my profile are mostly just for trying out stuff.

Noteworthy contributions to Open Source

void-packages - The Void source packages collection
Source.Python - Project that uses boost::python to allow scripters to interact with Valve's Source-engine
Backtrace - A very small (less 4.5K) stack unwinder designed for deeply embedded C applications running on the ARM Cortex-M family of microprocessors by Red Rocket Computing, LLC

gmakec's People

Contributors

Watchers

gmakec's Issues

Parallelism

Add explicit target dependencies to allow parallel builds. Something like:

targets:
  - name: target-one
    ...
  
  - name: target-two
    ...
    depends:
      - target-one

Skip rebuilding if not needed

Tsoding has a very cool solution to this problem, which he implements in this video: https://www.youtube.com/watch?v=wH963jJ1lRM

Basically using touch correctly. We can and should port that mechanism to Go as well. Makes sense for big projects like raylib. And thanks to Tsoding we can actually get it right! :)

Add target references

Something like

targets:
  - name: bla
    ...
    output: build/bla.o

  - name: use-bla-output
    ...
    sources:
      - ref:bla.output

Add cmake style subdirectories

maybe

CMake style compiler capabilities

This is a huge one. CMake for example checks for pthread, sys/types, etc. capabilities/files. I'm not sure how to go about this. We could probably get inspiration from CMake modules, though: https://github.com/Kitware/CMake/tree/master/Modules

compilers:
  - path: gcc
    checks:
      ...

# also applies to target-specific compilers:
targets:
  - compiler:
    path: gcc
    checks:
      ...

Also, it would be nice to let the developer disable those default checks:

compilers:
  - path: gcc
    checks:
      default: false # defaults to true

Also also, the developer should be able to define their own checks:

compilers:
  - path: gcc
    checks:
      default: true # for completeness
      custom:
        - name: My compiler check
          type: compile
          source: my/compiler/check.c
        - name: My filesystem check
          type: filesystem
          source: my/custom/header.h

Where type: compile would compile the file using path, and type: filesystem would check if the file is present on the system. If the check failed, an error message will be displayed prefixed by the value of name.

This structure is also easy to replicate in this project's source tree.

All of this would automatically resolve the configure_files TODO in https://github.com/thetredev/gmakec/blob/main/pkg/configure_file_definition.go#L16 (// TODO: make this "cmake complete" and probably more fleixble...), because we would have a giant variable store (like CMakes CMAKE_ variables) to configure files from.

Building only a selection of targets instead of the whole project

Something like make [<target> <target> <target>] would be nice to have.

Add target hooks

Something like

targets:
  - compiler:
    ....
    hooks:
      preConfigure: <command>
      postConfigure: <command>
      preBuild: <command>
      postBuild: <command>

Target hooks will not work in all container environments

Some container environments won't have a shell, e.g. FROM scratch. Thus, I think we should let the user decide which shell to use and how, something like:

# sh
hooks:
  - shell: /bin/sh -c
    step: preConfigure
    command: echo "test"

# bash
hooks:
  - shell: /bin/bash -c
    step: preConfigure
    command: echo "test"

# none
hooks:
  - shell: none
    step: preConfigure
    command: /my/script.sh

# none (omit `shell` completely)
hooks:
  - step: preConfigure
    command: /my/script.sh

actions keyword

Instead of only commands (for hooks), we could also create an actions keyword. Something like:

actions:
  - id: python-version
    name: Define python version as compiler option
    shell: bash -c
    environment:
      - system:PATH
    command: python3 -V
    output:
      - define: SYSTEM_PYTHON_VERSION="<output>"

  - id: python-script
    name: Running python script
    shell: bash -c
    environment:
      - system:all # appends $(env) to command (not sure if needed when running in bash shell, but it's a showcase)
    command: python3 /some/python/script.py
    output: null # for completeness
  
  - id: multi-output
    name: Handle output in multiple ways
    shell: bash -c
    environment:
      - system:PATH # appends ${PATH} to command (not sure if needed when running in bash shell, but it's a showcase)
    command: hostname --ip-address
    output:
      - define: SYSTEM_HOSTNAME="<output>" # the developer has to make sure the output is exactly 1 line, gmakec doesn't care
      - file:
          type: text # or binary, fifo, socket:unix, socket:tcp, socket:udp
          path: /my/file/path.txt
          mode: append # or create
  
  - id: no-shell
    name: No shell command
    environment:
      - MY_VAR=MY_VALUE # commands without a shell don't have any environment variables set, so this will be the only one in this case
    command: /some/script/which/uses/MY_VAR.sh
    output: null

targets:
  - compiler:
    ...
    hooks:
      - step: preConfigure
        actions:
          - python-version
          - python-script
      - step: postBuild
        actions:
          - name: Some post build script # define completely new action here for this hook, no ID needed
            ...

This serves as a first idea. Gotta go to work now :D

Target hook postConfigure is executed multiple times

Add more capabilities to actions keyword

TODO

Platform independency

Currently only Linux (and probably macOS, untested) is supported. We sould add something like:

targets:
  - compiler:
    ...
    sources:
      - path: src/shared.c
      - path: src/linux.c
        platform: linux
      - path: src/macOS.c
        platform: macOS
      - path: src/windows.c
        platform: windows

Things to keep in mind:

file line endings
compiler support for platforms
might as well add support for targets:platform
probably more

Handle errors in goroutines

Fixing issue #1 introduced a goroutine to make parallel builds possible. Error handling is not trivial.

Add yaml imports

imports:
  - path: ../other-project/gmakec.yaml
    # filter by target, omit for full import 
    targets:
      - target1
      - targrt2

CMake style 'find' modules

As an alternative to fixing issue #10, we could also simply provide lightweight CMake-like Find*.cmake modules for specific files/libraries. That way, we don't need to test the compiler for its capabilities and we can focus on finding files, basically. As a drawback, the developer will have to build the project and watch out for compiler error messages, should the compiler lack certain capabilities needed to build the project. I personally believe this is a better approach than the typical configure based one. We're nearing the end of 2023 after all. And yes, this is an excuse as I don't have any motivation to fix issue #10 right now. Not sure if we could additionally face legal issues as I have no idea if one can basically copy the intellectual property of Kitware, even if it's BSD-3 licensed (and I have no idea what that license really allows and what it doesn't). CMake's copyright.txt file only reads you can modify CMake's source code if you want, at least that's what I'm getting out of that. Not my cup of tea to be honest.

Even so, I'm thinking about something like this:

compilers:
  - path: gcc
    find:
      - type: library
        names:
          - glew
      - type: library
        names:
          - glut
      - type: filesystem
        names:
          - python3
          - python3.11
          - python

# The path to the python executable would resolve the same way as $(realpath $(which python3)) would
# All of the above would also apply to targets:compiler of course