Dynamic build scripts
60 views
Skip to first unread message
brandonc
Jul 14, 2011, 2:08:03 AM7/14/11
to Bounce Framework
I like the idea of writing build scripts in the native language of the
project so bounce appeals to me.
Though, what I don't like is that I have to compile my targets into a
binary. I want my build script to be responsive.
I was thinking of attempting to hack a version of bounce that uses the
newest Mono.CSharp compiler-as-a-service classes or even
Microsoft.CSharp.CSharpCodeProvider (which allegedly uses csc.exe
internally) to generate the requisite assemblies without the
intermediate step of having to produce targets.dll. I think today's
dev versions of Mono support enough .net 3/4 features to make today's
bounce scripts compile.
Has any previous thought been given to try and dynamically compile
bounce build scripts? I'd like to hear about that. Some other
advantages I can think of: no bounce library references or extra
projects in your solution.
Some disadvantages: No compile time error checking for build scripts.
Reduced performance. Mono dependency. (although Mono.CSharp and Bounce
dll's could be ILMerged into bounce.exe to mitigate dependency
problems)
What are your thoughts?
project so bounce appeals to me.
Though, what I don't like is that I have to compile my targets into a
binary. I want my build script to be responsive.
I was thinking of attempting to hack a version of bounce that uses the
newest Mono.CSharp compiler-as-a-service classes or even
Microsoft.CSharp.CSharpCodeProvider (which allegedly uses csc.exe
internally) to generate the requisite assemblies without the
intermediate step of having to produce targets.dll. I think today's
dev versions of Mono support enough .net 3/4 features to make today's
bounce scripts compile.
Has any previous thought been given to try and dynamically compile
bounce build scripts? I'd like to hear about that. Some other
advantages I can think of: no bounce library references or extra
projects in your solution.
Some disadvantages: No compile time error checking for build scripts.
Reduced performance. Mono dependency. (although Mono.CSharp and Bounce
dll's could be ILMerged into bounce.exe to mitigate dependency
problems)
What are your thoughts?
Tim Macfarlane
Jul 14, 2011, 5:58:07 AM7/14/11
to bouncef...@googlegroups.com
Has been considered, and for small projects definitely worth doing. Reason we haven't done it yet is the size of our current projects makes it easier to have the builds in a VS project.
Probably something like looking for a Bounce\Targets.cs, or even Bounce.cs in current or parent directories, compiling and running it. Some disadvantages are that you won't be able to easily link to external libs without additional config, but perhaps not a great problem for most projects.
The non-mono version could just use (as you say) the MS C# provider. Perhaps we build binaries for mono too? (PS haven't tested bounce on mono yet...)
Tim.
brandonc
Jul 14, 2011, 1:07:20 PM7/14/11
to Bounce Framework
Interestingly, Mono.CSharp.dll doesn't require a mono environment to
work so it will work for MS and Mono environments. We could
redistribute (or ilmerge) that dll with bounce.
As you say, there is a configuration challenge when referencing DLLs
(or maybe even other build config options such as CPU configuration?).
I was thinking that maybe bounce could just reference all assemblies
found in the Bounce folder.
Thanks for your consideration
Brandon
On Jul 14, 3:58 am, Tim Macfarlane <timmacfarl...@gmail.com> wrote:
> Has been considered, and for small projects definitely worth doing. Reason
> we haven't done it yet is the size of our current projects makes it easier
> to have the builds in a VS project.
>
> Probably something like looking for a Bounce\Targets.cs, or even Bounce.cs
> in current or parent directories, compiling and running it. Some
> disadvantages are that you won't be able to easily link to external libs
> without additional config, but perhaps not a great problem for most
> projects.
>
> The non-mono version could just use (as you say) the MS C# provider. Perhaps
> we build binaries for mono too? (PS haven't tested bounce on mono yet...)
>
> Tim.
>
work so it will work for MS and Mono environments. We could
redistribute (or ilmerge) that dll with bounce.
As you say, there is a configuration challenge when referencing DLLs
(or maybe even other build config options such as CPU configuration?).
I was thinking that maybe bounce could just reference all assemblies
found in the Bounce folder.
Thanks for your consideration
Brandon
On Jul 14, 3:58 am, Tim Macfarlane <timmacfarl...@gmail.com> wrote:
> Has been considered, and for small projects definitely worth doing. Reason
> we haven't done it yet is the size of our current projects makes it easier
> to have the builds in a VS project.
>
> Probably something like looking for a Bounce\Targets.cs, or even Bounce.cs
> in current or parent directories, compiling and running it. Some
> disadvantages are that you won't be able to easily link to external libs
> without additional config, but perhaps not a great problem for most
> projects.
>
> The non-mono version could just use (as you say) the MS C# provider. Perhaps
> we build binaries for mono too? (PS haven't tested bounce on mono yet...)
>
> Tim.
>
Tim Macfarlane
Jul 14, 2011, 1:09:44 PM7/14/11
to bouncef...@googlegroups.com
Linking with Bounce\*.dll is not a bad idea. Wonder if we can inherit the CPU configuration from the bounce.exe?
Reply all
Reply to author
Forward
0 new messages