BenPyton / OsciView

An SFML project to simulate an oscilloscope view of the computer audio output

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Compiling on Linux

hartwork opened this issue · comments

Hi @BenPyton, cool project!

The readme says for Mac/Linux I should "Clone the repo and build the project." but there are no build system files I could find that are not for Visual Studio (OsciView.sln) but CMake, Meson, Makefile or something. Assuming there is no such thing, if I succeed in making a small CMake based build system for this project, would a pull request adding that plus a small CI based on GitHub Actions to catch future build breakage be welcome?

Best, Sebastian

Hi hartwork,

Of course a pull request is welcomed :)

I've always preferred CMake because of cross platform, but for my personal projects like this one I use Visual Studio so I can start coding in one click.

For CI however I've never used github actions... What do you plan to do with it? Is there any restrictions, like having a server hosted elsewhere?

In all cases, you create separate pull request for each, and discuss that at this time :)

Also, it is not related to your question, but I need to check on my computer, I remember that I changed some little things for the FFT computation. I used a third party code to improve greatly the performances.

Best regards.

Hi hartwork,

Of course a pull request is welcomed :)

@BenPyton cool!

For CI however I've never used github actions... What do you plan to do with it? Is there any restrictions, like having a server hosted elsewhere?

Good question, let me say a few words on that. GitHub Actions is free for all public repositories like this one. We add one or more YAML files to a specific folder in Git to tell it what to do and then it will run some code for every Git push, every change to a pull request, or periodically like once a week. The key idea is to ensure that the code not only builds without errors today but also that whenever e.g. a pull requests is going to break the build in the future it will not go unnoticed but be caught by GitHub Actions.
To see that in action elsewhere, I have a pull request JanKleprlik/AudioVisualiser#3 where I'm contributing something very close to what I'm envisioning us to do here. The past runs from that case can be inspected at https://github.com/hartwork/AudioVisualiser/actions if you like. Happy to answer questions on CI and GitHub Actions.

What do you think?

In all cases, you create separate pull request for each, and discuss that at this time :)

I would prefer to keep them combined because the CI will be the test that what I did in the build system works in practice, not just on my machine. Let me demo the combined version (with separate commits) and we can extract things from there before merging as needed, if I didn't mange to convince you by that time.

What do you think?

Also, it is not related to your question, but I need to check on my computer, I remember that I changed some little things for the FFT computation. I used a third party code to improve greatly the performances.

Sounds good!

Okay!
I'm curious of how it works :)

@BenPyton glad to hear! Take your time to look around and/or play with it if you like, happy to answer questions.