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.
2 Likes
+1 this has been on my list for some time too!
3 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.
2 Likes
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.
2 Likes
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
2 Likes