Castle trunk
4 views
Skip to first unread message
Mauricio Scheffer
Nov 2, 2009, 10:40:42 AM11/2/09
to HORN Development
Hi, I'm a Horn newbie and a Castle committer. Castle has been recently
splitting its subprojects to stand-alone repositories and we're
considering removing the old trunk once this migration is done.
However, it would be still useful to build all the projects at once.
Can this be done with Horn?
The Castle descriptor at http://github.com/dagda1/hornget/blob/master/ioc/castle/castle.boo
is checking out from the current trunk, is there any way to make it
run all the other Castle descriptors instead? Plus, it would have to
copy the binary dependencies between projects.
Thanks,
Mauricio
splitting its subprojects to stand-alone repositories and we're
considering removing the old trunk once this migration is done.
However, it would be still useful to build all the projects at once.
Can this be done with Horn?
The Castle descriptor at http://github.com/dagda1/hornget/blob/master/ioc/castle/castle.boo
is checking out from the current trunk, is there any way to make it
run all the other Castle descriptors instead? Plus, it would have to
copy the binary dependencies between projects.
Thanks,
Mauricio
Paul Cowan
Nov 2, 2009, 10:53:03 AM11/2/09
to horn-dev...@googlegroups.com
We do not actually ever depend on the http://github.com/dagda1/hornget/blob/master/ioc/castle/castle.boo directly.
We were using that as the repository to get the other bits of castle.
The reason for this is because castle depends on nhibernate and nhibernate depends on castle. We had a circular reference which meant we did some hackery to get all the castle bits to build individually.
The reason for this is because castle depends on nhibernate and nhibernate depends on castle. We had a circular reference which meant we did some hackery to get all the castle bits to build individually.
>> is there any way to make it run all the other Castle descriptors instead
I would think we would have a descriptor for all the new bits of castle and just let users download the bits they are interested in.
You can see here that we have no castle listing for everything:
http://www.hornget.net/packages/ioc/
Horn at the minute needs to reference a code repository and needs to have a build_with instruction in order to work.
We could certainly build something that referenced all the castle subprojects but we still need something at the top of the tree to build.
You can see here that we have no castle listing for everything:
http://www.hornget.net/packages/ioc/
Horn at the minute needs to reference a code repository and needs to have a build_with instruction in order to work.
We could certainly build something that referenced all the castle subprojects but we still need something at the top of the tree to build.
I hope this makes sense.
Cheers
Paul Cowan
Cutting-Edge Solutions (Scotland)
http://thesoftwaresimpleton.blogspot.com/
Cheers
Paul Cowan
Cutting-Edge Solutions (Scotland)
http://thesoftwaresimpleton.blogspot.com/
2009/11/2 Mauricio Scheffer <mauricio...@gmail.com>
Mauricio Scheffer
Nov 2, 2009, 11:28:44 AM11/2/09
to HORN Development
I just saw this issue http://code.google.com/p/hornget/issues/detail?id=10
, I think it's exactly what I have in mind.
We could just list all the Castle projects on the command-line and
horn would resolve the dependency order and compile everything right?
On Nov 2, 12:53 pm, Paul Cowan <dag...@scotalt.net> wrote:
> We do not actually ever depend on thehttp://github.com/dagda1/hornget/blob/master/ioc/castle/castle.boodirectly.
>
> We were using that as the repository to get the other bits of castle.
>
> The reason for this is because castle depends on nhibernate and nhibernate
> depends on castle. We had a circular reference which meant we did some
> hackery to get all the castle bits to build individually.
>
> >> is there any way to make it run all the other Castle descriptors instead
>
> I would think we would have a descriptor for all the new bits of castle and
> just let users download the bits they are interested in.
>
> You can see here that we have no castle listing for everything:
>
> http://www.hornget.net/packages/ioc/
>
> Horn at the minute needs to reference a code repository and needs to have a
> build_with instruction in order to work.
>
> We could certainly build something that referenced all the castle
> subprojects but we still need something at the top of the tree to build.
>
> I hope this makes sense.
>
> Cheers
>
> Paul Cowan
>
> Cutting-Edge Solutions (Scotland)
>
> http://thesoftwaresimpleton.blogspot.com/
>
> 2009/11/2 Mauricio Scheffer <mauricioschef...@gmail.com>
, I think it's exactly what I have in mind.
We could just list all the Castle projects on the command-line and
horn would resolve the dependency order and compile everything right?
On Nov 2, 12:53 pm, Paul Cowan <dag...@scotalt.net> wrote:
> We do not actually ever depend on thehttp://github.com/dagda1/hornget/blob/master/ioc/castle/castle.boodirectly.
>
> We were using that as the repository to get the other bits of castle.
>
> The reason for this is because castle depends on nhibernate and nhibernate
> depends on castle. We had a circular reference which meant we did some
> hackery to get all the castle bits to build individually.
>
> >> is there any way to make it run all the other Castle descriptors instead
>
> I would think we would have a descriptor for all the new bits of castle and
> just let users download the bits they are interested in.
>
> You can see here that we have no castle listing for everything:
>
> http://www.hornget.net/packages/ioc/
>
> Horn at the minute needs to reference a code repository and needs to have a
> build_with instruction in order to work.
>
> We could certainly build something that referenced all the castle
> subprojects but we still need something at the top of the tree to build.
>
> I hope this makes sense.
>
> Cheers
>
> Paul Cowan
>
> Cutting-Edge Solutions (Scotland)
>
> http://thesoftwaresimpleton.blogspot.com/
>
Paul Cowan
Nov 2, 2009, 11:50:21 AM11/2/09
to horn-dev...@googlegroups.com
That issue still remains an untouched issue unfortunately.
But yes, it would work out the dependency order and do it's stuff.
2009/11/2 Mauricio Scheffer <mauricio...@gmail.com>
Gauthier Segay
Nov 3, 2009, 7:15:39 PM11/3/09
to HORN Development
I'm newbie to horn and git, but managed to put three descriptors for
castle (core,dp,validator) in a fork:
git://github.com/smoothdeveloper/hornget.git
I've used the dependencies section of the package descriptor but I'm
not sure how horn is behaving.
the castle dp descriptor is set with
dependencies:
castle.core >> "Castle.Core"
after a build, looking at "Working" dir ends up with lib containing
Castle.Core.dll + pdb so it's the version fed by horn
I'm also uncertain if castle build script overrides framework specific
libs with the root lib dir or if it is required to explicitely state
framework specific subdirectory (which will hardwritten -> is not
ideal)
the chain goes like that up to castle.component.validator, I'll
continue a bit this week but feedback / idea / help to fix the
framework specific dependencies and ensure the build is not picking
the default dependencies is welcome
On Nov 2, 4:40 pm, Mauricio Scheffer <mauricioschef...@gmail.com>
wrote:
castle (core,dp,validator) in a fork:
git://github.com/smoothdeveloper/hornget.git
I've used the dependencies section of the package descriptor but I'm
not sure how horn is behaving.
the castle dp descriptor is set with
dependencies:
castle.core >> "Castle.Core"
after a build, looking at "Working" dir ends up with lib containing
Castle.Core.dll + pdb so it's the version fed by horn
I'm also uncertain if castle build script overrides framework specific
libs with the root lib dir or if it is required to explicitely state
framework specific subdirectory (which will hardwritten -> is not
ideal)
the chain goes like that up to castle.component.validator, I'll
continue a bit this week but feedback / idea / help to fix the
framework specific dependencies and ensure the build is not picking
the default dependencies is welcome
On Nov 2, 4:40 pm, Mauricio Scheffer <mauricioschef...@gmail.com>
wrote:
> Hi, I'm a Horn newbie and a Castle committer. Castle has been recently
> splitting its subprojects to stand-alone repositories and we're
> considering removing the old trunk once this migration is done.
> However, it would be still useful to build all the projects at once.
> Can this be done with Horn?
>
> The Castle descriptor athttp://github.com/dagda1/hornget/blob/master/ioc/castle/castle.boo
> splitting its subprojects to stand-alone repositories and we're
> considering removing the old trunk once this migration is done.
> However, it would be still useful to build all the projects at once.
> Can this be done with Horn?
>
Paul Cowan
Nov 3, 2009, 11:15:28 PM11/3/09
to horn-dev...@googlegroups.com
Hi gauthier,
Much kudos for helping out. The castle descriptors are the base for a lot of the other horn descriptors.
I will look at this tonight, uk time
I am not sure i understand the problem you are having and wonder if you could further explain.
are you saying that horn is resolving castle.core to the lib did but the castle build script is then overriding it?
On 4 Nov 2009 00:15, "Gauthier Segay" <gauthie...@gmail.com> wrote:
I'm newbie to horn and git, but managed to put three descriptors for
castle (core,dp,validator) in a fork:
git://github.com/smoothdeveloper/hornget.git
I've used the dependencies section of the package descriptor but I'm
not sure how horn is behaving.
the castle dp descriptor is set with
dependencies:
castle.core >> "Castle.Core"
after a build, looking at "Working" dir ends up with lib containing
Castle.Core.dll + pdb so it's the version fed by horn
I'm also uncertain if castle build script overrides framework specific
libs with the root lib dir or if it is required to explicitely state
framework specific subdirectory (which will hardwritten -> is not
ideal)
the chain goes like that up to castle.component.validator, I'll
continue a bit this week but feedback / idea / help to fix the
framework specific dependencies and ensure the build is not picking
the default dependencies is welcome
On Nov 2, 4:40 pm, Mauricio Scheffer <mauricioschef...@gmail.com>
wrote:
> Hi, I'm a Horn newbie and a Castle committer. Castle has been recently > splitting its subprojects...
> The Castle descriptor athttp://github.com/dagda1/hornget/blob/master/ioc/castle/castle.boo
> is checking out from the current trunk, is there any way to make it > run all the other Castle des...
Paul Cowan
Nov 4, 2009, 11:32:11 AM11/4/09
to horn-dev...@googlegroups.com
Hi gauthier,
The caste.core descriptor in git is blank:
http://github.com/smoothdeveloper/hornget/blob/master/frameworks/castle.core/castle.core.boo
I wonder if this is the problem?
Cheers
Paul
The caste.core descriptor in git is blank:
http://github.com/smoothdeveloper/hornget/blob/master/frameworks/castle.core/castle.core.boo
I wonder if this is the problem?
Cheers
Paul
2009/11/4 Paul Cowan <dag...@scotalt.net>
--
Paul Cowan
Nov 4, 2009, 11:45:10 AM11/4/09
to horn-dev...@googlegroups.com
Hi Gauthier,
It is also worth noting that each depend entry of the depends section of the dsl equates to one .dll.
For example in the old castle structure I would have to reference the both Castle.Microkernel and Castle.Windsor in order to get both .dlls as dependencies like this. "castle.windsor" on the left of the right bit operator is the descriptor and the right part is the library we want to include. I think it was important to do it this way as including everything can lead to trouble:
It is also worth noting that each depend entry of the depends section of the dsl equates to one .dll.
For example in the old castle structure I would have to reference the both Castle.Microkernel and Castle.Windsor in order to get both .dlls as dependencies like this. "castle.windsor" on the left of the right bit operator is the descriptor and the right part is the library we want to include. I think it was important to do it this way as including everything can lead to trouble:
dependencies:
dependency "castle.windsor" >> "Castle.MicroKernel"
dependency "castle.windsor" >> "Castle.Windsor"
Gauthier Segay
Nov 4, 2009, 7:24:39 PM11/4/09
to HORN Development
Hello Paul,
I just pushed the right descriptor for castle.core
back to my problem:
> I am not sure i understand the problem you are having and wonder if you
could further explain.
In the new castle separated repositories, the dependencies are stored
in a framework specific directory, see each subfolders here:
http://svn.castleproject.org:8080/svn/castle/DynamicProxy/trunk/lib/
> are you saying that horn is resolving castle.core to the lib did but the
castle build script is then overriding it?
I didn't checked the new nant script, but in the previous main build
scripts (default.build in castle/trunk) theses are copied to the
output dir in this order:
- platform neutral dependencies
- if running silverlight, silverlight dependencies
- platform specific dependencies
so the platform neutral files are overwritten by the specific one
it mean that the shared_library directive should be modified according
to the selected FrameworkVersion, something like that:
shared_library "lib/net-3.5"
It feels there is something to do with FrameworkVersion, but it
doesn't feel ok to put a scripty resolution scheme in the package
descriptor.
Is there support for conditional structures in the descriptors or
should the shared_library be hard coded?
> It is also worth noting that each depend entry of the depends section of the
> dsl equates to one .dll.
> [example]
ok thanks for clearing theses for me, I'll also take care including
additional dependencies (such as NH for AR) with the next descriptors
On Nov 4, 5:45 pm, Paul Cowan <dag...@scotalt.net> wrote:
> Hi Gauthier,
>
> It is also worth noting that each depend entry of the depends section of the
> dsl equates to one .dll.
>
> For example in the old castle structure I would have to reference the both
> Castle.Microkernel and Castle.Windsor in order to get both .dlls as
> dependencies like this. "castle.windsor" on the left of the right bit
> operator is the descriptor and the right part is the library we want to
> include. I think it was important to do it this way as including everything
> can lead to trouble:
>
> dependencies:
> dependency "castle.windsor" >> "Castle.MicroKernel"
> dependency "castle.windsor" >> "Castle.Windsor"
>
> Cheers
>
> Paul Cowan
>
> Cutting-Edge Solutions (Scotland)
>
> http://thesoftwaresimpleton.blogspot.com/
>
> 2009/11/4 Paul Cowan <dag...@scotalt.net>
>
>
>
> > Hi gauthier,
>
> > The caste.core descriptor in git is blank:
>
> >http://github.com/smoothdeveloper/hornget/blob/master/frameworks/cast...
I just pushed the right descriptor for castle.core
back to my problem:
> I am not sure i understand the problem you are having and wonder if you
could further explain.
in a framework specific directory, see each subfolders here:
http://svn.castleproject.org:8080/svn/castle/DynamicProxy/trunk/lib/
> are you saying that horn is resolving castle.core to the lib did but the
castle build script is then overriding it?
scripts (default.build in castle/trunk) theses are copied to the
output dir in this order:
- platform neutral dependencies
- if running silverlight, silverlight dependencies
- platform specific dependencies
so the platform neutral files are overwritten by the specific one
it mean that the shared_library directive should be modified according
to the selected FrameworkVersion, something like that:
shared_library "lib/net-3.5"
It feels there is something to do with FrameworkVersion, but it
doesn't feel ok to put a scripty resolution scheme in the package
descriptor.
Is there support for conditional structures in the descriptors or
should the shared_library be hard coded?
> It is also worth noting that each depend entry of the depends section of the
> dsl equates to one .dll.
ok thanks for clearing theses for me, I'll also take care including
additional dependencies (such as NH for AR) with the next descriptors
On Nov 4, 5:45 pm, Paul Cowan <dag...@scotalt.net> wrote:
> Hi Gauthier,
>
> It is also worth noting that each depend entry of the depends section of the
> dsl equates to one .dll.
>
> For example in the old castle structure I would have to reference the both
> Castle.Microkernel and Castle.Windsor in order to get both .dlls as
> dependencies like this. "castle.windsor" on the left of the right bit
> operator is the descriptor and the right part is the library we want to
> include. I think it was important to do it this way as including everything
> can lead to trouble:
>
> dependencies:
> dependency "castle.windsor" >> "Castle.MicroKernel"
> dependency "castle.windsor" >> "Castle.Windsor"
>
> Cheers
>
> Paul Cowan
>
> Cutting-Edge Solutions (Scotland)
>
> http://thesoftwaresimpleton.blogspot.com/
>
> 2009/11/4 Paul Cowan <dag...@scotalt.net>
>
>
>
> > Hi gauthier,
>
> > The caste.core descriptor in git is blank:
>
>
> > I wonder if this is the problem?
>
> > Cheers
>
> > Paul
>
> > 2009/11/4 Paul Cowan <dag...@scotalt.net>
>
> > Hi gauthier,
>
> >> Much kudos for helping out. The castle descriptors are the base for a lot
> >> of the other horn descriptors.
>
> >> I will look at this tonight, uk time
>
> >> I am not sure i understand the problem you are having and wonder if you
> >> could further explain.
>
> >> are you saying that horn is resolving castle.core to the lib did but the
> >> castle build script is then overriding it?
>
> > I wonder if this is the problem?
>
> > Cheers
>
> > Paul
>
> > 2009/11/4 Paul Cowan <dag...@scotalt.net>
>
> > Hi gauthier,
>
> >> Much kudos for helping out. The castle descriptors are the base for a lot
> >> of the other horn descriptors.
>
> >> I will look at this tonight, uk time
>
> >> I am not sure i understand the problem you are having and wonder if you
> >> could further explain.
>
> >> are you saying that horn is resolving castle.core to the lib did but the
> >> castle build script is then overriding it?
>
Paul Cowan
Nov 5, 2009, 4:32:49 AM11/5/09
to horn-dev...@googlegroups.com
Hi Gauthier
This is quite a tricky one and unique to castle's approach.
This is quite a tricky one and unique to castle's approach.
So what you are saying is that horn should resolve the castle specific dependencies, e.g. Castle.Core.dll etc that it has built into "SharedLibs/net-3.5"?
What about non-castle specific horn dependencies like Nhibernate etc., do they belong in this folder ?
The way the shared_library directive works in the Dsl is that you are specifying the root of the shared library folder. The code will then recurse round every directory in this root and replace all the dependencies it finds.
I think for now we need to specify "SharedLibs/net-3.5" for now.
I do not think we should concentrate on net-2.0 for horn.
We will need to concentrate on .NET-4.0 which opens up many challenges.
What about non-castle specific horn dependencies like Nhibernate etc., do they belong in this folder ?
The way the shared_library directive works in the Dsl is that you are specifying the root of the shared library folder. The code will then recurse round every directory in this root and replace all the dependencies it finds.
I think for now we need to specify "SharedLibs/net-3.5" for now.
I do not think we should concentrate on net-2.0 for horn.
We will need to concentrate on .NET-4.0 which opens up many challenges.
2009/11/5 Gauthier Segay <gauthie...@gmail.com>
Gauthier Segay
Nov 5, 2009, 7:33:35 PM11/5/09
to HORN Development
Hello Paul, please see my answer bellow
On Nov 5, 10:32 am, Paul Cowan <dag...@scotalt.net> wrote:
> Hi Gauthier
>
> This is quite a tricky one and unique to castle's approach.
>
I thought it was a clean approach for the task, and it's grounded on
the nant target names. I'll almost bet that some multitargetting
projects using nant are probably relying on a similar scheme.
Finding a clean solution to express theses dependency/target mapping
seems important because this already is a concern for thoses that are
using mono or silverlight (or both).
A first idea would be to have something like (I'm using a metaphor) a
permalink customization setting in blog engine:
nant_target = Framework35
shared_library = "lib/${nant_target}/"
that could fit with nant, but may require some more possibilities to
integrate with other build systems.
I'm also far from actual horn codebase to have an idea of what is
defined and what is possible to add.
> So what you are saying is that horn should resolve the castle specific
> dependencies, e.g. Castle.Core.dll etc that it has built into
> "SharedLibs/net-3.5"?
>
yes (to "lib/net-3.5" in the new projects), sorry if that was not
clear in my explanation (this intermingled with explanation about the
target settings)
> What about non-castle specific horn dependencies like Nhibernate etc., do
> they belong in this folder ?
>
yes, same same, a castle project may have external and/or castle
dependencies, they are treated the same way in the new structure
(please correct if I'm wrong)
> The way the shared_library directive works in the Dsl is that you are
> specifying the root of the shared library folder. The code will then
> recurse round every directory in this root and replace all the dependencies
> it finds.
>
that's an idea that sprinkled to me, it feel a bit harsh half of the
time, I'm unsure but there might be some unwanted side effects
according to build structure of some projects
> I think for now we need to specify "SharedLibs/net-3.5" for now.
>
Ok I'll change the descriptors to net-3.5 when I resume the work
> I do not think we should concentrate on net-2.0 for horn.
>
> We will need to concentrate on .NET-4.0 which opens up many challenges.
>
I agree, however the potential horn user base may gain with
multitargeting support (mono / silverlight, and things to come) even
before net-4.0 is released.
> Cheers
>
> Paul Cowan
>
> Cutting-Edge Solutions (Scotland)
>
> http://thesoftwaresimpleton.blogspot.com/
>
> 2009/11/5 Gauthier Segay <gauthier.se...@gmail.com>
On Nov 5, 10:32 am, Paul Cowan <dag...@scotalt.net> wrote:
> Hi Gauthier
>
> This is quite a tricky one and unique to castle's approach.
>
the nant target names. I'll almost bet that some multitargetting
projects using nant are probably relying on a similar scheme.
Finding a clean solution to express theses dependency/target mapping
seems important because this already is a concern for thoses that are
using mono or silverlight (or both).
A first idea would be to have something like (I'm using a metaphor) a
permalink customization setting in blog engine:
nant_target = Framework35
shared_library = "lib/${nant_target}/"
that could fit with nant, but may require some more possibilities to
integrate with other build systems.
I'm also far from actual horn codebase to have an idea of what is
defined and what is possible to add.
> So what you are saying is that horn should resolve the castle specific
> dependencies, e.g. Castle.Core.dll etc that it has built into
> "SharedLibs/net-3.5"?
>
clear in my explanation (this intermingled with explanation about the
target settings)
> What about non-castle specific horn dependencies like Nhibernate etc., do
> they belong in this folder ?
>
dependencies, they are treated the same way in the new structure
(please correct if I'm wrong)
> The way the shared_library directive works in the Dsl is that you are
> specifying the root of the shared library folder. The code will then
> recurse round every directory in this root and replace all the dependencies
> it finds.
>
time, I'm unsure but there might be some unwanted side effects
according to build structure of some projects
> I think for now we need to specify "SharedLibs/net-3.5" for now.
>
> I do not think we should concentrate on net-2.0 for horn.
>
> We will need to concentrate on .NET-4.0 which opens up many challenges.
>
multitargeting support (mono / silverlight, and things to come) even
before net-4.0 is released.
> Cheers
>
> Paul Cowan
>
> Cutting-Edge Solutions (Scotland)
>
> http://thesoftwaresimpleton.blogspot.com/
>
Paul Cowan
Nov 6, 2009, 1:42:13 AM11/6/09
to horn-dev...@googlegroups.com
>> shared_library = "lib/${nant_target}/"
I really like the idea or maybe we could have shared_library = "lib/${FrameWorkVersion}/"
Where FrameWorkVerrsion could be a global parameter that is set either in the build script, as an external parameter etc. much in the same way these things work in nant.
If we could incorporate these variables or parameters into the descriptor into this would make the DSL so much more flexible.
Where FrameWorkVerrsion could be a global parameter that is set either in the build script, as an external parameter etc. much in the same way these things work in nant.
If we could incorporate these variables or parameters into the descriptor into this would make the DSL so much more flexible.
>> I agree, however the potential horn user base may gain with multitargeting support (mono / silverlight, and things to come) eve
I completely agree. Contributors with mono and silverlight needs and experience would be very welcome to help make this a reality.
2009/11/6 Gauthier Segay <gauthie...@gmail.com>
John Simons
Nov 8, 2009, 11:16:53 AM11/8/09
to HORN Development
Instead we could prepopulate the output directory.
When we build castle we automatically create a eg /build/net-3.5
directory and the output assemblies get built into there and
dependencies copied. Because we are using the nant copy task to copy
the dependencies into there we could just instruct the descriptor to
copy the Assemblies into there instead because the nant copy task
won't override it.
Thoughts?
On Nov 6, 9:42 am, Paul Cowan <dag...@scotalt.net> wrote:
> >> shared_library = "lib/${nant_target}/"
>
> I really like the idea or maybe we could have
>
> shared_library = "lib/${FrameWorkVersion}/"
>
> Where FrameWorkVerrsion could be a global parameter that is set either in
> the build script, as an external parameter etc. much in the same way these
> things work in nant.
>
> If we could incorporate these variables or parameters into the descriptor
> into this would make the DSL so much more flexible.
>
> >> I agree, however the potential horn user base may gain with multitargeting
>
> support (mono / silverlight, and things to come) eve
>
> I completely agree. Contributors with mono and silverlight needs and
> experience would be very welcome to help make this a reality.
>
> Cheers
>
> Paul Cowan
>
> Cutting-Edge Solutions (Scotland)
>
> http://thesoftwaresimpleton.blogspot.com/
>
> 2009/11/6 Gauthier Segay <gauthier.se...@gmail.com>
When we build castle we automatically create a eg /build/net-3.5
directory and the output assemblies get built into there and
dependencies copied. Because we are using the nant copy task to copy
the dependencies into there we could just instruct the descriptor to
copy the Assemblies into there instead because the nant copy task
won't override it.
Thoughts?
On Nov 6, 9:42 am, Paul Cowan <dag...@scotalt.net> wrote:
> >> shared_library = "lib/${nant_target}/"
>
> I really like the idea or maybe we could have
>
> shared_library = "lib/${FrameWorkVersion}/"
>
> Where FrameWorkVerrsion could be a global parameter that is set either in
> the build script, as an external parameter etc. much in the same way these
> things work in nant.
>
> If we could incorporate these variables or parameters into the descriptor
> into this would make the DSL so much more flexible.
>
> >> I agree, however the potential horn user base may gain with multitargeting
>
> support (mono / silverlight, and things to come) eve
>
> I completely agree. Contributors with mono and silverlight needs and
> experience would be very welcome to help make this a reality.
>
> Cheers
>
> Paul Cowan
>
> Cutting-Edge Solutions (Scotland)
>
> http://thesoftwaresimpleton.blogspot.com/
>
Paul Cowan
Nov 8, 2009, 2:14:36 PM11/8/09
to horn-dev...@googlegroups.com
Hi John,
The way horn works is that after it has built it dependency tree, it builds each dependency and outputs the result of each build into the ./horn/result folder before building the .
It will then select any copy from this folder any dependencies that are specified in the dsl, for example, in the descriptor castle.templateengine.boo it has the following section:
The way horn works is that after it has built it dependency tree, it builds each dependency and outputs the result of each build into the ./horn/result folder before building the .
It will then select any copy from this folder any dependencies that are specified in the dsl, for example, in the descriptor castle.templateengine.boo it has the following section:
shared_library "lib"
dependencies:
depend "castle.nvelocity" >> "NVelocity"
If we execute horn -insall:castle.templateengine
It will build castle.nvelocity and output the result into the /.horn/result folder, it will then iterate round the directory structure that is specified in the shared_library statement and replace any occurrences of the NVelocity.dll it finds.
If we execute horn -insall:castle.templateengine
It will build castle.nvelocity and output the result into the /.horn/result folder, it will then iterate round the directory structure that is specified in the shared_library statement and replace any occurrences of the NVelocity.dll it finds.
Then the nant script horn will call nant and the nant script will copy the contents of the lib into the build directory.
Is this not the correct behaviour as we are updating the lib folder before nant runs.
I am not familiar with the new castle build scripts. Does the nant script actually overwrite these .dlls?
Is this not the correct behaviour as we are updating the lib folder before nant runs.
I am not familiar with the new castle build scripts. Does the nant script actually overwrite these .dlls?
2009/11/8 John Simons <johnsi...@yahoo.com.au>
John Simons
Nov 9, 2009, 5:47:11 AM11/9/09
to HORN Development
Ok, I see now.
In that case it will work fine :)
The castle nant script does not modify the dlls in the lib folder or/
and subfolders.
Cheers
John
> 2009/11/8 John Simons <johnsimons...@yahoo.com.au>
> ...
>
> read more »- Hide quoted text -
>
> - Show quoted text -
In that case it will work fine :)
The castle nant script does not modify the dlls in the lib folder or/
and subfolders.
Cheers
John
>
> read more »- Hide quoted text -
>
> - Show quoted text -
Reply all
Reply to author
Forward
0 new messages