[Bf-cycles] Cycles standalone repository

Nathan Letwory nathan at mcneel.com
Mon Nov 17 12:22:51 CET 2014

Hash: SHA1

On 17/11/2014 12:18, Sergey Sharybin wrote:
> Yes, think having a branch in git.b.o/cycles.git is better.

Since this is fine I'd like to ask permission to create a
ccsycles_master branch. For my case I still can use the entire repo as
submodule, I'll need to fix some of my project files, but no further
major surgery is required. Also for my project I don't really mind all
the extra files, I'll write in my own docs to just ignore those ;)

> As for the submodule -- that's really a bummer because you can't
> use an external repo folder as the submodule. Because basically we
> only need cycles.git/src to be hooked into  intern/cycles. So the
> downsides of the submodule:

I can see the problems you mention for usage as submodule in
blender.git though. I have not really a strong opinion on that, so
will leave that to you and anyone else to decide how to do that in the
future. I'm perfectly fine with the process for Blender/Cycles
development as you wrote in response to Thomas Dinges on direction.

> - We'll have examples, standalone CMake file which we'll be
> basically skipping, third party libs folder from cycles repo in
> cycles working tree. That adds some unwanted crowdness to the
> sources tree. - It'll ruing everyone's patches they made so far for
> cycles.

The question here probably should be: is the effort for recreating
patches exhorbitantly huge, or would the one-time pain be low enough
to make a move possible?

> Ideas about how to improve stuff in the future:
> - have a branch in cycles.git which would only have src/ folder,
> which is easy to do originally with `git subtree split`, after
> that checrry-picking between branches in cycles.git should be
> rather fine. A bit dirty approach, yeah.. - We can agree on having
> some duplicated libs in the working tree (such as cuew, clew) and
> which are ignored. Plus agree on breaking xisting patches to
> blender and use cycles as a submodule.

In my case will I already have duplicate modules. That said, it'll
probably not hard for me to copy over project files in my own branch
and use the clew/cuew libraries from the Cycles submodule.

> - Think of something else?

Not ATM. I'm happy with already the current progress, making some of
my work to keep in sync with main Cycles development much smoother. So

/Nathan Letwory
Developer at Robert McNeel & Associates

> For now i think having a sync script is good enough. have least
> affect on everyone's exiting workflow, saving some time for
> gooseberry development as well :)
> On Mon, Nov 17, 2014 at 1:34 PM, Nathan Letwory <nathan at mcneel.com 
> <mailto:nathan at mcneel.com>> wrote:
> Hi,
> Amendment to my previous message: Perhaps I could work directly in
> a branch on git.blender.org:cycles.git instead of redirecting
> through github.com <http://github.com>. That'd probably make it
> much easier also to merge any useful commits from my work back into
> Cycles master.
> /Nathan Letwory RhinoCycles Developer at Robert McNeel &
> Associates
> On 15/11/2014 17:54, Sergey Sharybin wrote:
>> Hi,
>> Last few evenings i've been working on making a dedicated 
>> repository for Cycles renderer and at this point it seems to be 
>> ready for public access now, even though some more work is 
>> required.
>> = Motivation =
>> Main motivation of creating standalone repository for Cycles is
>> to simplify access for new developers who wants to hack into
>> Cycles code but don't want to bother cloning the whole Blender
>> repository and setting up environment for blender compilation.
>> It was kind of possible to only compile Cycles from Blender 
>> repository as well, but that process was really tedious.
>> = What repository contains =
>> Repository contains the full history of Cycles, starting from
>> the original commit to the Blender SVN. This means it's possible
>> to track down every change in the sources. The only thing here
>> is that it's not possible to compile old sources. This is
>> because build system for standalone repository was added just now
>> and trying to put it somewhere in the past was rather tricky.
>> Sources are mainly a direct dump from Blender, so it shouldn't
>> be difficult to keep Cycles in Blender and standalone
>> repositories in sync. There are a bit of changes to build system
>> which we'll need to backport to blender (namely CMake variables
>> name convention).
>> Repository contains README file which describes how to compile 
>> Cycles. Compilation is so called "works for me", so more tweaks 
>> are likely needed before compilation becomes flawless for 
>> everyone.
>> *NOTE*: Windows is not supported atm! It's because of some 
>> dependencies which are not so clear to get. Mainly OpenGL, GLUT 
>> and GLEW. Don't worry, we will support Windows eventually, we
>> just need to start from something!
>> The repository also contains folder with .xml examples, so it's 
>> really easy to test render engine just after compilation.
>> = Build system =
>> Currently CMake is used as a build system, and likely it'll be
>> it,
>> = Where the repository is =
>> It is on our server, read-only access is
>> git clone git://git.blender.org/cycles.git
> <http://git.blender.org/cycles.git>
>> <http://git.blender.org/cycles.git>
>> for write access (needs SSH key and you need to be a developer
>> of the project)
>> git clone git at git.blender.org:cycles.git
>> To browse repository online please visit:
>> https://developer.blender.org/diffusion/C/
>> = Authors =
>> The repository contains the file with everyone who contributed
>> to Cycles. This is somewhat common for all open source projects
>> to have such a file.
>> Currently this file contains authors of commits, so if someone 
>> submitted patch which was committed by someone else please let
>> me know -- that'd be easier than reading all the commit messages 
>> searching for such information.
>> = Synchronization with Blender =
>> Ideally we'll need to have some automated way to sync changes 
>> between Blender and Cycles, but it is not done yet. Exact way
>> how to keep things in sync i'll publish later.
>> For now we can do manual synchronization, which is not THAT bad.
>> = Known TODOs =
>> - Windows build is not supported at this moment. - Logging
>> option is exposed as an option but wouldn't work now. -
>> Installation target is not tested and would need more work. -
>> Compiled .oso files are not put to the final location, so manual
>> copy is required for now. - Set up mailing list for commits (if
>> we need one?)
>> I'm pretty much sure i forgot to put some information in this
>> email which i wanted, but the mail becomes too long already, so
>> i'd rather wrap up now and answer the questions as they arrive.
>> -- With best regards, Sergey Sharybin
>> _______________________________________________ Bf-cycles
>> mailing list Bf-cycles at blender.org
>> <mailto:Bf-cycles at blender.org> 
>> http://lists.blender.org/mailman/listinfo/bf-cycles
> _______________________________________________ Bf-cycles mailing
> list Bf-cycles at blender.org <mailto:Bf-cycles at blender.org> 
> http://lists.blender.org/mailman/listinfo/bf-cycles
> -- With best regards, Sergey Sharybin
> _______________________________________________ Bf-cycles mailing
> list Bf-cycles at blender.org 
> http://lists.blender.org/mailman/listinfo/bf-cycles

- -- 
Nathan Letwory
Version: GnuPG v1.4.10 (MingW32)


More information about the Bf-cycles mailing list