[Bf-cycles] Cycles standalone repository

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


-----BEGIN PGP SIGNED MESSAGE-----
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
thanks!

/Nathan Letwory
RhinoCycles
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)

iQEcBAEBAgAGBQJUadqLAAoJEKtfN7KsE0TtboEIAKWL0qjy6/S6HEdv0YaAMC+c
NZt2lPwKH6MtLoiwJJzUFNbMiKjIX0w7m8zNRkCd20Ux70CI4jWRoyrkuGfLH71D
JkHmQWMIuRO4w8yTu1wFNSKx9ptJRmNW/d1YdLONbI79zowW9Oz9vfIi7vx1x3mr
1GslniepNqKekOisHiwAqR0Q3dfuDu0tmaG+DHAkfKpj3WauNzOVPcMk/vGCv5Pk
mEYv32AVG+7B6GgWZylKw1YFTqd94VgL0xB4EylgxWDHtgEp/NDN9LTLNNCEPmzx
szlWm7+cge5d1OuLTHKAfVh5O3YU3bkvxXr6/rULrjmcGiPArFeNpmlTNV/eNFM=
=q8Zi
-----END PGP SIGNATURE-----


More information about the Bf-cycles mailing list