On Wed, Nov 3, 2010 at 7:56 PM, Tomas Matousek <tomas.matou...@microsoft.com > wrote:
> Please don't add yet another build system. > I completely agree with that, though I'm interested why there are 3 sets of all csproj in every project directory? As far > Generating .csproj files is not the right way to go. The project files are > and should be the primary metadata storage for the build system. If you work > in VS and add a new file VS will add it into csproj. > If you would like to build some packages (like rpms) you can write a .proj > file that does that. Like we do for building .msis (see Msi\Installer.proj). > If there is something msbuild/xbuild doesn't support you can write a custom > task that does that. > If there is some bug in xbuild that prevents you to do what you need the > bug needs to be fixed in xbuild. > > Other than supporting packages, what's exactly is the scenario that doesn't > work today that you want to support? I don't understand what do you mean by > "Allows multiple (as many as you want) out of tree builds ...". Can you be > more specific? > > Tomas > > -----Original Message----- > From: ironruby-core-boun...@rubyforge.org [mailto: > ironruby-core-boun...@rubyforge.org] On Behalf Of Alistair Bush > Sent: Wednesday, November 03, 2010 11:18 AM > To: ironruby-core@rubyforge.org > Subject: Re: [Ironruby-core] Very Very initial CMake support > > > Having multiple building systems is counterproductive, it's hard to > > maintain all of them. > > > > In General I agree. thats is why ultimately I would like cmake to support > creating of csproj files. That would need to be implemented, but has > already > been proven possible by cmakes other VS proj support. > > For this project I don't believe that maintaining cmake will be all that > difficult. it supports wildcards (Dir/*.cs) when selecting which files to > build which means that in most cases no changes will need to be made. There > is an exception to this which im planning on raising in a separate thread. > Currently that work I have done with cmake has encountered a large number > of > "abandoned" files within the repo. It seems these classes have been > migrated > into System.* but only removed from the proj file. This is really really > messy. > > > Is cmake using xbuild to buil the dlls or does it all the file linking > > by itself? > > Nope it calls the compiler directly. Sadly I think it would be very > difficult > to maintain xbuild to do what I want it to do. Ultimately we need to get > the Runtime/ directory out of the tree (or at least make linking against it > optional). There are also other benefits. > > * It also makes pkg-config support very easy. > * Allows multiple (as many as you want) out of tree builds so that you can > for example run tests on standard debug build as well as a silverlight build > simultaneously. You also don't have to be constantly switch configs. you > can easy target multiple versions of mono/.NET etc etc etc. > * supports creating of debs and rpms directly. > > > > > On Wed, Nov 3, 2010 at 11:54 AM, Alistair Bush <ali_b...@gentoo.org> > wrote: > > > I have started playing around with cmake to see whether it could help > out > > > iron* and dlr. I have therefore started implementing CMake makefiles > to > > > build > > > the dlr (Runtime) part of ironruby, install those dlls into the gac and > > > generate *.pc files for them. I have tested it on mono-2.8 (requires > > > mono-2.8) > > > and am aware that windows .NET support is broken (but very possible) > > > > > > cmake also supports creating deb's and rpm's which will be done in the > > > future > > > hopefully. The potential is also there for it to generate csproj files > > > (already supports other VS file types) > > > > > > To play around with it > > > > > > git clone git://github.com/alistair/ironruby.git > > > mkdir build > > > mkdir install > > > cd build (out of tree builds, oh how I love them ) > > > cmake ../repo/Runtime/ > > > make > > > make DESTDIR=../install install > > > > > > > > > After this you should have > > > > > > install $ find > > > . > > > ./usr > > > ./usr/lib64 > > > ./usr/lib64/mono > > > ./usr/lib64/mono/Microsoft.Scripting.Metadata > > > > > > > ./usr/lib64/mono/Microsoft.Scripting.Metadata/Microsoft.Scripting.Metadat > > > a.dll ./usr/lib64/mono/Microsoft.Dynamic > > > ./usr/lib64/mono/Microsoft.Dynamic/Microsoft.Dynamic.dll > > > ./usr/lib64/mono/Microsoft.Scripting > > > ./usr/lib64/mono/Microsoft.Scripting/Microsoft.Scripting.dll > > > ./usr/lib64/mono/Microsoft.Scripting.Core > > > ./usr/lib64/mono/Microsoft.Scripting.Core/Microsoft.Scripting.Core.dll > > > ./usr/lib64/mono/gac > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Metadata > > > > > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Metadata/1.1.0.10__7f709c5b71357 > > > 6e1 > > > > > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Metadata/1.1.0.10__7f709c5b71357 > > > 6e1/Microsoft.Scripting.Metadata.dll > > > ./usr/lib64/mono/gac/Microsoft.Dynamic > > > ./usr/lib64/mono/gac/Microsoft.Dynamic/1.1.0.10__7f709c5b713576e1 > > > > > > > ./usr/lib64/mono/gac/Microsoft.Dynamic/1.1.0.10__7f709c5b713576e1/Microso > > > ft.Dynamic.dll ./usr/lib64/mono/gac/Microsoft.Scripting > > > ./usr/lib64/mono/gac/Microsoft.Scripting/1.1.0.10__7f709c5b713576e1 > > > > > > > ./usr/lib64/mono/gac/Microsoft.Scripting/1.1.0.10__7f709c5b713576e1/Micro > > > soft.Scripting.dll ./usr/lib64/mono/gac/Microsoft.Scripting.Core > > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Core/1.1.0.10__7f709c5b713576e1 > > > > > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Core/1.1.0.10__7f709c5b713576e1/ > > > Microsoft.Scripting.Core.dll ./usr/local > > > ./usr/local/lib > > > ./usr/local/lib/pkgconfig > > > ./usr/local/lib/pkgconfig/microsoft.scripting.metadata.pc > > > ./usr/local/lib/pkgconfig/microsoft.scripting.core.pc > > > ./usr/local/lib/pkgconfig/microsoft.dynamic.pc > > > ./usr/local/lib/pkgconfig/microsoft.scripting.pc > > > > > > still lots of work to do, but hopefully you enjoy. > > > > > > Alistair. > > > _______________________________________________ > > > Ironruby-core mailing list > > > Ironruby-core@rubyforge.org > > > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
