Running on the trunk: Building Rhino Commons
Well, it looks like I have to share the big secret of how to keep Rhino Commons in sync with both NHibernate & Castle. The secret is never opening Visual Studio and doing it all from the command line. Here is the magic formula:
D:\OSS>cd nhibernate D:\OSS\nhibernate>svn up D:\OSS\nhibernate>nant D:\OSS\nhibernate>cd.. D:\OSS>cd Castle D:\OSS\Castle>svn up D:\OSS\Castle>nant D:\OSS\Castle>copy ..\nhibernate\build\NHibernate-2.0.0.Alpha1-debug\bin\net-2.0\*.* build\net-2.0\debug /y D:\OSS\Castle>nant D:\OSS\Castle>copy ..\nhibernate\build\NHibernate-2.0.0.Alpha1-debug\bin\net-2.0\*.* ..\rhino-tools\SharedLibs\NHibernate /y D:\OSS\Castle>copy build\net-2.0\debug\*.* ..\rhino-tools\SharedLibs\Castle\*.* /y D:\OSS\Castle>cd.. D:\OSS>cd rhino-tools D:\OSS\rhino-tools>msbuild BuildAll.build
Comments
Do you ever feel like a mad scientist? :)
Thanks for sharing this...I'll give it a go...
Hmm and what about NHibernate's dependencies on Castle's libraries (like DynamicProxy2)? Can they be safely ignored?
I'm doing it in different order:
build Castle trunk
copy required castle libraries to NHibernate
build NHibrenate trunk
copy required NHibernate libraries to Castle
build Castle trunk again
And, BTW, there were some Castle projects that were implementing (if that's the right term) ISession, and they don't have implementations for some latest ISession additions. However, maybe it's fixed by now.
I had to fix those ISession differences manually (they just are decorated in Castle). The .csproj file for Monorail choked during the build, too....but that was last week.
What if you added NHibernate and Castle as SVN Externals underneath Rhino-tools? Then an SVN Update to Rhino-tools would update NHibernate and Castle as well.
Just note, do not delete any libs, just update and copy.
I have a script that deletes the deps and things fail b/c Castle depends on nullables and NHibernate trunk is no longer producing nullables.