Automatic Gitignore

hi. i think it might make sense to add automatic gitignore files that contain the builds and the juceLibraryCode for every new project made with the projucer and the tutorials.

1 Like

+1 this has been on my list for some time too!

2 Likes

I personally do like to commit the project files (like JUCE does in their repo) since that way you can build projects/browse code in an IDE without having to use the Projucer or even have it installed. I have my own gitignore that ignores all the temporary build files…

So if that’s implemented, I’d suggest to have it optional.

1 Like

I would very much be unhappy if running the PJ modified my gitignore files in anyway.
For me, the PJ is a tool used to manage projects and generate IDE files, I don’t think it should start messing with repository configurations. It would also be very difficult to get this right with any other .gitignore file contents.

I often have repos with multiple JUCE projects in and often not in the root of the repo.

Is perhaps what you’re looking for just a useful template to populate new repos with?

6 Likes

Yep - the main point here is that the PJ’s job is to create projects, not repositories. It’s best that it stays neutral as far as source-control goes.

This FR sounds to me like a “treat-the-symptom-rather-than-the-cause” request… I think that if you find yourself creating so many new repos that this would save you significant effort, then you probably need to ask yourself why on earth you’re creating all those repos in the first place. And if for some strange reason you really do need lots of repos, then automating that process would be better done at a higher level than the PJ.

I don’t quite get what you’re saying here, I can’t believe you’re suggesting that everything created with JUCE should live in subfolders of a mono-repo?

Fully agree that this shouldn’t be part of PJ though, for a start there is more than one source control system, and it really not so difficult to create a script if you want to start JUCE projects from a custom template.

No, but a repo is a long-term thing - you create one (or several) for a project and then use them for months or years.

If you’re churning over so many new repos that you’re finding it annoying to do the initial set-up on them manually, then that just sounds a bit odd to me.

2 Likes

your arguments totally make sense to me. i just thought the projucer is not only meant to make new projects but also to make this as easy as possible and since no one would ever want the builds folder in their gitignore i thought it would be cool to just have it included automatically. maybe even a little extra window where people can declare what their default gitignore should look like, so it’s customizable. and everyone who doesn’t want anything of it could just leave it empty, nah?

1 Like

My take on it is that there is no harm in creating a default basic .gitignore file to at least keep the Build folder out of a resulting repo. Other project creation tools that I’ve used, e.g. for React Native and Cargo (Rust) create a default .gitignore file for a project.
Obviously it should not overwrite an existing one when a jucer project is saved.

This would avoid project Build folders being committed by mistake (especially by beginners), as most of the time this is undesirable. It’s happened to me a good few times. I also generally keep AppConfig.h in source control but the rest of the JuceLibraryCode folder out. That might be a matter of opinion though.

Also - .gitignore files can be at any level of a repo, so if you have a mono-repo of a few JUCE projects each with its own .gitignore it would also work for those…

1 Like

Why don‘t you just keep a default gitignore file in some documents folder and copy it if needed?
+1 for PJ not messing with repos, please don‘t

2 Likes

The request is not suggesting messing with existing repos, just creating a simple default .gitignore file for a new JUCE project… come on guys its not that far out.

1 Like

i hope no one felt too annoyed by my suggestion. i’m just a noob who thinks that some aspects could be more straight-forward, but i don’t have the ability to see the whole picture yet so i’m sure my opinion on a lot of stuff isn’t very meaningful yet

To me it seems to raise the bigger and unanswered question: Quo vadis, Projucer

  • There was a period, when Introjucer became Projucer, when it aimed to be a complete IDE, Rapid GUI Prototype tool and project management.
  • At some point for whatever reason, the route became to be only a project management/IDE project setup tool (maybe the JIT was too ambitious, or lost interest over other ideas).
  • And lately the wish becomes louder to get rid of the necessity of using Projucer alltogether by using cmake or whatever existing build toolchain.

At one point it would be good to hear, what the plans for Projucer are (or if there are any for that matter)

There will always be the two extremes, those who want to use Projucer as much as possible, and others, who want it gone, so probably you won’t be able to please them all…

5 Likes

woah! ok. i am totally against getting rid of projucer! to everyone who is responsible for juce: please don’t do that!! for me as a huge noob this tool was essential to get started and i love how it lets you select what you wanna do right in the beginning and then sets everything up perfectly. i wouldn’t use it as an ide, but it’s totally cool the way it is now

edit: please always remember that many people who try to make vst plugins are just musicians that got excited about dsp, so we kinda need a little helping hand about some things that don’t seem important to actual programmers sometimes

1 Like