I should also add that im going to continue because 1) I want to learn more cmake 2) there is also the possiblity to generate cmake files from csproj files :)
> > Please don't add yet another build system. > > > > 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. > > It can [1] be automatically available to cmake to consume. Only those > cases where files are only applicable for silverlight would there be any > changes required and you already have to hand crank the csproj files > anyway. > > > 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. > > Currently that sounds like more work, not less. > > > Other than supporting packages, what's exactly is the scenario that > > doesn't work today that you want to support? > > Mainly the complete and easy separation of dlr from ironruby. The ablility > to install ironruby into a location of my pleasing with a simple command. > easy pkg-config support. The ability to develop and compile against > multiple versions of mono/moonlight/etc. Probably a few more but I > haven't thought of them :) > > > 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? > > maybe "out of source" would explain it more. > > if we take this example here > > git clone git://github.com/alistair/ironruby.git > mkdir build > mkdir install > cd build > cmake ../repo/Runtime/ > make > make DESTDIR=../install install > > the build dir is an "out of tree/source build". after executing make (aka > a compile task) no changes have been made to the git repo. No new dll's, > etc, etc. They are all located within build. rm -R build is the > equivilent of running a clean task. > > this build directory also is a configuration cache. So currently the > csproj have mulitple PropertyGroup conditional on > $(Configuration)|$(Platform)'. eg. Debug|AnyCPU, v2Debug|AnyCPU ( > Release/v2Release and Silverlight versions as well). > > with cmake you just go. > > mkdir silverlight-build-debug; cd silverlight-build-debug; > cmake -D CONF_VAR_NAME=SilverlightDebug ../repo/Runtime/ > and you are then able to build both debug (from above) and silverlight > debug config targets (compile, test, etc) side-by-side simultantiously. > No building one and then selecting from a drop down to build the next > configuration. No need to have .gitignore either. > > - Alistair. > > > [1] I say "can" because the Runtime tree (at least) is a mess at the > moment. Far to many redundant files left over. Sadly you just sync (copy > is a more appropriate term) entire directories between projects repos so > now even if I fix it within the ironruby tree I have to worry about them > coming back in the next sync. > > > 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.Met > > > > ad at 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.dl > > > > l ./usr/lib64/mono/gac > > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Metadata > > > > > > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Metadata/1.1.0.10__7f709c5b7 > > > > 13 57 6e1 > > > > > > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Metadata/1.1.0.10__7f709c5b7 > > > > 13 57 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/Mic > > > > ro so 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/M > > > > ic ro soft.Scripting.dll > > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Core > > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Core/1.1.0.10__7f709c5b7135 > > > > 76 e1 > > > > > > > > ./usr/lib64/mono/gac/Microsoft.Scripting.Core/1.1.0.10__7f709c5b71357 > > > > 6e 1/ 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 _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
