Hi, I know I may be asking some pretty obvious questions to people with professional programming experience, so I basically have no programming experience other than very basic ones, so I don’t expect I can actually provide anything useful to the code in Blender. But I just wish to see what this is about. My question is as the title says, how should I test my changes to Blender?
I have cloned the Blender repository. I have built it into an executable. I wish to make changes to the source code, and then rebuild it. But I have tried it before and messed up so badly that it failed to rebuild the executable. I didn’t know how to fix it, so I deleted everything and rebuilt it from scratch, but that took a long time. So, how should I organise the Blender files so that I can avoid that? Do I keep a spare copy of the Blender source files so I don’t have to download them again if I messed up the source code?
Hi,
since you cloned the repository already, you should already made contact with git, a version control system that makes these kind of things easily possible.
In short: Once you check out Blender, you have a copy of the upstream repository. Per default you are in the main branch. You can keep that unmodified and update it regularly by using make update.
For you changes, you can create a new branch with git checkout -b my-feature main, where my-feature is the name of your branch. You can experiment around in there, change code and if things break you can either create a new branch, revert the changes or simply switch back to main. No need to delete everything and do a new checkout.
Thanks. I created another branch, checked out to it and made some changes in the code. But after I switched back to the main branch, and I open up the source code files. They have been modified. How do I keep the files in the main branch unmodified, and only modify the files in whatever branch I am?
Sorry I am still confused. I have just tried to do that. Let’s say I have a main and testing branches. I switch to testing branch. Make some changes in a file. Save it. Commit the changes. Now I switch back to the main branch. I open up the changed file, and still see the changes. Is that normal? How do I change the file back to the original version?
D:\Blender-git\blender>git status
On branch main
Your branch is up to date with 'origin/main'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: CMakeLists.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
CMakeCache.txt
CMakeFiles/
no changes added to commit (use "git add" and/or "git commit -a")
The file I changed in the testing branch is /source/blender/windowmanager/intern/wm_init_exit.cc
have no business being in your source folder, not sure what you did to get them there, but best to remove them.
beyond that it says you made changes to CMakeLists.txt which you did not commit
you can use git diff to see said changes, if they are changes you want, switch back to your banch and commit them, after that git status should come back clean
Hm, I have no idea how they got there either. I deleted them. I also committed the changes to CMakeLists.txt.
Now both git diff and git status are clean, which isn’t what I expected. I expected /source/blender/windowmanager/intern/wm_init_exit.cc to show up because I modified it when I was in the testing branch and committed it.
Oh well, I think I am starting to understand how this works, but it still feels a little bit confusing. Do you guys also type commands to handle different branches, or is there a UI? I know there is Github, but it looks like many git commands don’t exist as buttons there.
Personally i use a mix of command line and tortoisegit, but there’s so many of them out there, it’s kinda like picking your favourite Muppet, everyone will have a different favourite and some don’t like them at all.
Like LazyDodo, I find a mix of working from the command line and a git GUI works well.
I usually use the command line for “quick hits” – git status and git branch, etc… (git branch tells you what branch you are on, and what branches you have available – as you get more comfortable with using source control, you will probably make branches as you play around with ideas, but don’t necessarily want your code changes being mixed together.)
I usually use a GUI to review my changes – the “diff” between the source code you started with, and the changes that you made. You may find it convenient to also then “add” your source code files and “commit” there, too, since you are already in the tool. (Of course you can also do all of this from the command line as well.)
If you are feeling overwhelmed by the number of GUI tools on the page ThomasDinges posted, consider starting with SourceTree. They will all get the job done! But SourceTree has a nice, modern-looking UI, if nothing else (I have no connection with SourceTree other than as a user, and it hasn’t pissed me off yet which is a good starting point for any software!)
Hope this helps! Everyone feels a little overwhelmed by source control at first, I think. You will get used to the tools – and git can be a bit funky at times, especially from the command line – and develop your own workflow.
There are other questions I wish to ask. I know the answer depends on multiple factors, such as how powerful your CPU is, or whether it is a Debug Build. Right now, for Blender 4.4, roughly how long is the compile time for you guys for a full build?
And, in the Build Options documentation, it says it is recommended to use the Developer Build for faster builds. Does it mean it is faster than the Debug Build, or even faster than the normal build?
build time is as you mentioned highly depended on the hardware you have, my old system (i7-3770/32gb) 50 minutes or so, my current system (9550x/64gb) 7.5 minutes give or take.
The developer profile is just a debug build with some extra diagnostics enabled, it’s slower than a regular debug build in both build time and runtime speed due to the additional checks it performs, but those additional checks are good at highlighting common problems, so they help you write more bug free code. Still much faster to build than a release version of blender though.
You’re focusing on the wrong things here, build the build type you need to get your task done, not the thing that builds fastest but is useless in getting the job you have set out to do done. There is no single build type that is best for all situations.
I understand. It’s just that, being such a beginner, I doubt the debugging information will be useful to me. I am just excited to see changes I make, even if they are meaningless, so that’s why I am asking for the fastest build, and possibly a build that takes up less space. I am aware of the lite build, but I also don’t know what is missing from it.
