xcode and VM plugins
Locked
 
|
Hello, i just wonder, how one could force xcode to compile & link only those internal plugins, which is listed in plugins.int? This is sorta easy to do using makefiles.. but with xcode.. im lost.. Any ideas? -- Best regards, Igor Stasenko AKA sig. |
|
|
Xcode project display has a column with header icon looking like a circle with a dot in it. That column has checkboxes beside the files, checked = include in the build, unchecked = do not include. Files would need to be dragged into your project to be visible. Ken At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: > >Hello, > >i just wonder, how one could force xcode to compile & link only those >internal plugins, which is listed in >plugins.int? > >This is sorta easy to do using makefiles.. but with xcode.. im lost.. > >Any ideas? > >-- >Best regards, >Igor Stasenko AKA sig. |
|
|
In reply to this post by Igor Stasenko
On 19 December 2010 18:01, Ken G. Brown <[hidden email]> wrote: > > Xcode project display has a column with header icon looking like a circle with a dot in it. That column has checkboxes beside the files, checked = include in the build, unchecked = do not include. Files would need to be dragged into your project to be visible. > Thanks, captain obvious :) Now tell me how i call force xcode to automatically do not include some/all .c files into build, based on the contents of plugins.int file ? :) > Ken > > At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: >> >>Hello, >> >>i just wonder, how one could force xcode to compile & link only those >>internal plugins, which is listed in >>plugins.int? >> >>This is sorta easy to do using makefiles.. but with xcode.. im lost.. >> >>Any ideas? >> >>-- >>Best regards, >>Igor Stasenko AKA sig. > > -- Best regards, Igor Stasenko AKA sig. |
|
|
afaik... you can't Let me know if you find out a way :P cheers, Esteban El 19/12/2010, a las 2:31p.m., Igor Stasenko escribió: > > On 19 December 2010 18:01, Ken G. Brown <[hidden email]> wrote: >> >> Xcode project display has a column with header icon looking like a circle with a dot in it. That column has checkboxes beside the files, checked = include in the build, unchecked = do not include. Files would need to be dragged into your project to be visible. >> > > Thanks, captain obvious :) > > Now tell me how i call force xcode to automatically do not include > some/all .c files into build, based on the contents of > plugins.int file ? > :) > >> Ken >> >> At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: >>> >>> Hello, >>> >>> i just wonder, how one could force xcode to compile & link only those >>> internal plugins, which is listed in >>> plugins.int? >>> >>> This is sorta easy to do using makefiles.. but with xcode.. im lost.. >>> >>> Any ideas? >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. |
|
|
On 19 December 2010 18:52, Esteban Lorenzano <[hidden email]> wrote: > > afaik... you can't > Let me know if you find out a way :P > it annoys me, that i can't tell it to build a VM with given set of internal plugins, or speaking more generally - with given configuration. > cheers, > Esteban > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Igor Stasenko
At 6:31 PM +0100 12/19/10, Igor Stasenko apparently wrote: >On 19 December 2010 18:01, Ken G. Brown <[hidden email]> wrote: >> >> Xcode project display has a column with header icon looking like a circle with a dot in it. That column has checkboxes beside the files, checked = include in the build, unchecked = do not include. Files would need to be dragged into your project to be visible. >> > >Thanks, captain obvious :) Well, I hope the obvious was helpful, if not, well, I tried... :) Not sure how much you have used Xcode. There are so many settings etc. that it takes awhile to grok and it's easy to miss the obvious sometimes. >Now tell me how i call force xcode to automatically do not include >some/all .c files into build, based on the contents of >plugins.int file ? >:) Thinking about that one...not sure at the moment, I suppose AppleScript could do something, but seems messy. Maybe find one of John's Xcode projects and see if he did something along those lines. I think he had one on svn somewhere at some point. I haven't been compiling VM's for quite some time now. There's an Xcode list that might be helpful. <http://lists.apple.com/mailman/listinfo/xcode-users> Ken > > Ken >> >> At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: >>> >>>Hello, >>> >>>i just wonder, how one could force xcode to compile & link only those >>>internal plugins, which is listed in >>>plugins.int? >>> >>>This is sorta easy to do using makefiles.. but with xcode.. im lost.. >>> >>>Any ideas? >>> >>>-- >>>Best regards, >>>Igor Stasenko AKA sig. >> >> > > > >-- >Best regards, >Igor Stasenko AKA sig. |
|
|
In reply to this post by Igor Stasenko
On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote: > > On 19 December 2010 18:01, Ken G. Brown <[hidden email]> wrote: > > > > At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: > >> > >>i just wonder, how one could force xcode to compile & link only those > >>internal plugins, which is listed in > >>plugins.int? > >> > >>This is sorta easy to do using makefiles.. but with xcode.. im lost.. > >> > >>Any ideas? > >> > > > > Xcode project display has a column with header icon looking like a circle with a dot in it. That column has checkboxes beside the files, checked = include in the build, unchecked = do not include. Files would need to be dragged into your project to be visible. > > > > Thanks, captain obvious :) > > Now tell me how i call force xcode to automatically do not include > some/all .c files into build, based on the contents of > plugins.int file ? > :) Hi Igor, I know next to nothing about xcode, but I would note that we are accumulating quite a few different build systems. As an individual user building a VM on my own computer, this is no problem. I just read the instructions provided by the platform maintainer, and all is well. I'm also quite happy to use a VMMakerTool that spits out the sources for my specific platform. But if you want to produce repeatable builds across a range of platforms, you are dealing with a different problem. The Cog branch deals with this by: 1) Have VMMaker always generate all the sources for all platforms. 2) Use repeatable build scripts or configure/make proceedures for each platform. However this does seem to rely on a collection of scripts and makefiles that must be maintained for each platform, and for Unix/Linux it is also using the old config process (with libtool etc) rather than Ian's newer CMake-based system that is currently in use for the Unix VM. In my own experience (limited primarily to building on Linux for my own use, as opposed to building and distributing to other users), I found that moving to CMake took some getting used to (damn, not another $#%@#%#@! build system ;-) but once I got accustomed to it, it works as advertised and does a good job of avoiding platform-specific problems, such as libtool failing to work for building 32 bit libraries on a 64 bit system, to cite a recent example. So if I were going to attempt to produce a repeatable, cross-platform build system, I would be inclined to take the following approach long term: 1) Adopt the Cog approach of generating a single set of source code from VMMaker for all platforms (no, that does not mean I want to get rid of the current VMMakerTool, but if I wanted to build for multiple platforms, it is better to use the Cog approach here). 2) Update the current Unix CMake to reflect the changes from the above (I assume Ian will want to do that). 3) Figure out how to replace the current build scripts for the other platforms with CMake. 4) Make it all work the same for Cog and the interpreter VM. To be clear, I do not personally plan to do the above (except for #1), but if I needed a cross-platform build system for a range of VMs, that is how I would attack the problem. Just my $0.02, and I suspect that you will be in an excellent position to offer your own perspective on this pretty soon ;-) Dave |
|
|
David, i agree that using CMake for building VM is good because it is cross-platform tool. So, it is obvious choice for automating building tasks. But not when you in developing/debugging mode, since you need UI to see what happens, (don't tell me gdb is all UI i need ;) That's where integrated dev environments like xcode rocks. So, i wonder if its possible to have a cake and eat it too :) On 19 December 2010 19:23, David T. Lewis <[hidden email]> wrote: > > On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote: >> >> On 19 December 2010 18:01, Ken G. Brown <[hidden email]> wrote: >> > >> > At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: >> >> >> >>i just wonder, how one could force xcode to compile & link only those >> >>internal plugins, which is listed in >> >>plugins.int? >> >> >> >>This is sorta easy to do using makefiles.. but with xcode.. im lost.. >> >> >> >>Any ideas? >> >> >> > >> > Xcode project display has a column with header icon looking like a circle with a dot in it. That column has checkboxes beside the files, checked = include in the build, unchecked = do not include. Files would need to be dragged into your project to be visible. >> > >> >> Thanks, captain obvious :) >> >> Now tell me how i call force xcode to automatically do not include >> some/all .c files into build, based on the contents of >> plugins.int file ? >> :) > > Hi Igor, > > I know next to nothing about xcode, but I would note that we are > accumulating quite a few different build systems. As an individual > user building a VM on my own computer, this is no problem. I just > read the instructions provided by the platform maintainer, and all > is well. I'm also quite happy to use a VMMakerTool that spits out > the sources for my specific platform. But if you want to produce > repeatable builds across a range of platforms, you are dealing with > a different problem. > > The Cog branch deals with this by: > 1) Have VMMaker always generate all the sources for all platforms. > 2) Use repeatable build scripts or configure/make proceedures for > each platform. > > However this does seem to rely on a collection of scripts and > makefiles that must be maintained for each platform, and for > Unix/Linux it is also using the old config process (with libtool > etc) rather than Ian's newer CMake-based system that is currently > in use for the Unix VM. > > In my own experience (limited primarily to building on Linux for > my own use, as opposed to building and distributing to other users), > I found that moving to CMake took some getting used to (damn, not > another $#%@#%#@! build system ;-) but once I got accustomed to it, > it works as advertised and does a good job of avoiding platform-specific > problems, such as libtool failing to work for building 32 bit libraries > on a 64 bit system, to cite a recent example. > > So if I were going to attempt to produce a repeatable, cross-platform > build system, I would be inclined to take the following approach > long term: > > 1) Adopt the Cog approach of generating a single set of source code > from VMMaker for all platforms (no, that does not mean I want to > get rid of the current VMMakerTool, but if I wanted to build for > multiple platforms, it is better to use the Cog approach here). > > 2) Update the current Unix CMake to reflect the changes from the > above (I assume Ian will want to do that). > > 3) Figure out how to replace the current build scripts for the > other platforms with CMake. > > 4) Make it all work the same for Cog and the interpreter VM. > > To be clear, I do not personally plan to do the above (except > for #1), but if I needed a cross-platform build system for a range > of VMs, that is how I would attack the problem. > > Just my $0.02, and I suspect that you will be in an excellent position > to offer your own perspective on this pretty soon ;-) > > Dave > > -- Best regards, Igor Stasenko AKA sig. |
|
|
On Sun, 19 Dec 2010, Igor Stasenko wrote: > > David, > i agree that using CMake for building VM is good because it is > cross-platform tool. > So, it is obvious choice for automating building tasks. > But not when you in developing/debugging mode, since you need UI to > see what happens, (don't tell me gdb is all UI i need ;) > That's where integrated dev environments like xcode rocks. There are free, cross-platform IDE's that support CMake and GDB, like Eclipse or NetBeans. So that can be unified too if you really want it to be. ;) Levente > > So, i wonder if its possible to have a cake and eat it too :) > > On 19 December 2010 19:23, David T. Lewis <[hidden email]> wrote: >> >> On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote: >>> >>> On 19 December 2010 18:01, Ken G. Brown <[hidden email]> wrote: >>>> >>>> At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: >>>>> >>>>> i just wonder, how one could force xcode to compile & link only those >>>>> internal plugins, which is listed in >>>>> plugins.int? >>>>> >>>>> This is sorta easy to do using makefiles.. but with xcode.. im lost.. >>>>> >>>>> Any ideas? >>>>> >>>> >>>> Xcode project display has a column with header icon looking like a circle with a dot in it. That column has checkboxes beside the files, checked = include in the build, unchecked = do not include. Files would need to be dragged into your project to be visible. >>>> >>> >>> Thanks, captain obvious :) >>> >>> Now tell me how i call force xcode to automatically do not include >>> some/all .c files into build, based on the contents of >>> plugins.int file ? >>> :) >> >> Hi Igor, >> >> I know next to nothing about xcode, but I would note that we are >> accumulating quite a few different build systems. As an individual >> user building a VM on my own computer, this is no problem. I just >> read the instructions provided by the platform maintainer, and all >> is well. I'm also quite happy to use a VMMakerTool that spits out >> the sources for my specific platform. But if you want to produce >> repeatable builds across a range of platforms, you are dealing with >> a different problem. >> >> The Cog branch deals with this by: >> 1) Have VMMaker always generate all the sources for all platforms. >> 2) Use repeatable build scripts or configure/make proceedures for >> each platform. >> >> However this does seem to rely on a collection of scripts and >> makefiles that must be maintained for each platform, and for >> Unix/Linux it is also using the old config process (with libtool >> etc) rather than Ian's newer CMake-based system that is currently >> in use for the Unix VM. >> >> In my own experience (limited primarily to building on Linux for >> my own use, as opposed to building and distributing to other users), >> I found that moving to CMake took some getting used to (damn, not >> another $#%@#%#@! build system ;-) but once I got accustomed to it, >> it works as advertised and does a good job of avoiding platform-specific >> problems, such as libtool failing to work for building 32 bit libraries >> on a 64 bit system, to cite a recent example. >> >> So if I were going to attempt to produce a repeatable, cross-platform >> build system, I would be inclined to take the following approach >> long term: >> >> 1) Adopt the Cog approach of generating a single set of source code >> from VMMaker for all platforms (no, that does not mean I want to >> get rid of the current VMMakerTool, but if I wanted to build for >> multiple platforms, it is better to use the Cog approach here). >> >> 2) Update the current Unix CMake to reflect the changes from the >> above (I assume Ian will want to do that). >> >> 3) Figure out how to replace the current build scripts for the >> other platforms with CMake. >> >> 4) Make it all work the same for Cog and the interpreter VM. >> >> To be clear, I do not personally plan to do the above (except >> for #1), but if I needed a cross-platform build system for a range >> of VMs, that is how I would attack the problem. >> >> Just my $0.02, and I suspect that you will be in an excellent position >> to offer your own perspective on this pretty soon ;-) >> >> Dave >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
|
|
In reply to this post by Igor Stasenko
Hi Igor: On 19 Dec 2010, at 19:48, Igor Stasenko wrote: > That's where integrated dev environments like xcode rocks. > > So, i wonder if its possible to have a cake and eat it too :) You can always use the makefile to build with Xcode. This way you do not have to maintain >1 build systems, and have most of the IDE benefits (except of course the drag'n'drop build system). Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 |
|
|
In reply to this post by Levente Uzonyi-2
On 19 December 2010 19:59, Levente Uzonyi <[hidden email]> wrote: > > On Sun, 19 Dec 2010, Igor Stasenko wrote: > >> >> David, >> i agree that using CMake for building VM is good because it is >> cross-platform tool. >> So, it is obvious choice for automating building tasks. >> But not when you in developing/debugging mode, since you need UI to >> see what happens, (don't tell me gdb is all UI i need ;) >> That's where integrated dev environments like xcode rocks. > > There are free, cross-platform IDE's that support CMake and GDB, like > Eclipse or NetBeans. So that can be unified too if you really want it to be. > ;) ouch.. Tried using NetBeans once... on a small C++ project.. Just two words: crawls, crashes. I can't imagine what will happen with it if you pass interp.c to it. xcode btw, also feels a bit shocked when it opens interp.c :) (takes around a minute for it, when you happily watching the rolling rainbow disc) > > > Levente > >> >> So, i wonder if its possible to have a cake and eat it too :) >> >> On 19 December 2010 19:23, David T. Lewis <[hidden email]> wrote: >>> >>> On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote: >>>> >>>> On 19 December 2010 18:01, Ken G. Brown <[hidden email]> wrote: >>>>> >>>>> At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: >>>>>> >>>>>> i just wonder, how one could force xcode to compile & link only those >>>>>> internal plugins, which is listed in >>>>>> plugins.int? >>>>>> >>>>>> This is sorta easy to do using makefiles.. but with xcode.. im lost.. >>>>>> >>>>>> Any ideas? >>>>>> >>>>> >>>>> Xcode project display has a column with header icon looking like a >>>>> circle with a dot in it. That column has checkboxes beside the files, >>>>> checked = include in the build, unchecked = do not include. Files would need >>>>> to be dragged into your project to be visible. >>>>> >>>> >>>> Thanks, captain obvious :) >>>> >>>> Now tell me how i call force xcode to automatically do not include >>>> some/all .c files into build, based on the contents of >>>> plugins.int file ? >>>> :) >>> >>> Hi Igor, >>> >>> I know next to nothing about xcode, but I would note that we are >>> accumulating quite a few different build systems. As an individual >>> user building a VM on my own computer, this is no problem. I just >>> read the instructions provided by the platform maintainer, and all >>> is well. I'm also quite happy to use a VMMakerTool that spits out >>> the sources for my specific platform. But if you want to produce >>> repeatable builds across a range of platforms, you are dealing with >>> a different problem. >>> >>> The Cog branch deals with this by: >>> 1) Have VMMaker always generate all the sources for all platforms. >>> 2) Use repeatable build scripts or configure/make proceedures for >>> each platform. >>> >>> However this does seem to rely on a collection of scripts and >>> makefiles that must be maintained for each platform, and for >>> Unix/Linux it is also using the old config process (with libtool >>> etc) rather than Ian's newer CMake-based system that is currently >>> in use for the Unix VM. >>> >>> In my own experience (limited primarily to building on Linux for >>> my own use, as opposed to building and distributing to other users), >>> I found that moving to CMake took some getting used to (damn, not >>> another $#%@#%#@! build system ;-) but once I got accustomed to it, >>> it works as advertised and does a good job of avoiding platform-specific >>> problems, such as libtool failing to work for building 32 bit libraries >>> on a 64 bit system, to cite a recent example. >>> >>> So if I were going to attempt to produce a repeatable, cross-platform >>> build system, I would be inclined to take the following approach >>> long term: >>> >>> 1) Adopt the Cog approach of generating a single set of source code >>> from VMMaker for all platforms (no, that does not mean I want to >>> get rid of the current VMMakerTool, but if I wanted to build for >>> multiple platforms, it is better to use the Cog approach here). >>> >>> 2) Update the current Unix CMake to reflect the changes from the >>> above (I assume Ian will want to do that). >>> >>> 3) Figure out how to replace the current build scripts for the >>> other platforms with CMake. >>> >>> 4) Make it all work the same for Cog and the interpreter VM. >>> >>> To be clear, I do not personally plan to do the above (except >>> for #1), but if I needed a cross-platform build system for a range >>> of VMs, that is how I would attack the problem. >>> >>> Just my $0.02, and I suspect that you will be in an excellent position >>> to offer your own perspective on this pretty soon ;-) >>> >>> Dave >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Levente Uzonyi-2
> There are free, cross-platform IDE's that support CMake and GDB, like Eclipse or NetBeans. So that can be unified too if you really want it to be. ;) please don't... I really hate those :( bah... eclipse is cool for java projects (all the good that can be a java project, of course), but not for anything else, IMHO. cheers, Esteban |
|
|
In reply to this post by Igor Stasenko
CONTENTS DELETED
The author has deleted this message.
|
|
|
On 19 December 2010 20:35, Marco Schmidt <[hidden email]> wrote: > > I'm using cmake and Xcode (beside Eclipse under Linux and MS VS2008) > with great success as cross plattform build system. You can generate > Xcode-project files with cmake -G"Xcode". There is support for cmake > in the non-cog branch (currently linux only?) > OH, that's interesting. (going to try it out) > Marco Schmidt > > > 2010/12/19 Igor Stasenko <[hidden email]>: >> >> On 19 December 2010 19:59, Levente Uzonyi <[hidden email]> wrote: >>> >>> On Sun, 19 Dec 2010, Igor Stasenko wrote: >>> >>>> >>>> David, >>>> i agree that using CMake for building VM is good because it is >>>> cross-platform tool. >>>> So, it is obvious choice for automating building tasks. >>>> But not when you in developing/debugging mode, since you need UI to >>>> see what happens, (don't tell me gdb is all UI i need ;) >>>> That's where integrated dev environments like xcode rocks. >>> >>> There are free, cross-platform IDE's that support CMake and GDB, like >>> Eclipse or NetBeans. So that can be unified too if you really want it to be. >>> ;) >> >> ouch.. >> Tried using NetBeans once... on a small C++ project.. >> Just two words: crawls, crashes. >> I can't imagine what will happen with it if you pass interp.c to it. >> xcode btw, also feels a bit shocked >> when it opens interp.c :) (takes around a minute for it, when you >> happily watching the rolling rainbow disc) >> >>> >>> >>> Levente >>> >>>> >>>> So, i wonder if its possible to have a cake and eat it too :) >>>> >>>> On 19 December 2010 19:23, David T. Lewis <[hidden email]> wrote: >>>>> >>>>> On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote: >>>>>> >>>>>> On 19 December 2010 18:01, Ken G. Brown <[hidden email]> wrote: >>>>>>> >>>>>>> At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: >>>>>>>> >>>>>>>> i just wonder, how one could force xcode to compile & link only those >>>>>>>> internal plugins, which is listed in >>>>>>>> plugins.int? >>>>>>>> >>>>>>>> This is sorta easy to do using makefiles.. but with xcode.. im lost.. >>>>>>>> >>>>>>>> Any ideas? >>>>>>>> >>>>>>> >>>>>>> Xcode project display has a column with header icon looking like a >>>>>>> circle with a dot in it. That column has checkboxes beside the files, >>>>>>> checked = include in the build, unchecked = do not include. Files would need >>>>>>> to be dragged into your project to be visible. >>>>>>> >>>>>> >>>>>> Thanks, captain obvious :) >>>>>> >>>>>> Now tell me how i call force xcode to automatically do not include >>>>>> some/all .c files into build, based on the contents of >>>>>> plugins.int file ? >>>>>> :) >>>>> >>>>> Hi Igor, >>>>> >>>>> I know next to nothing about xcode, but I would note that we are >>>>> accumulating quite a few different build systems. As an individual >>>>> user building a VM on my own computer, this is no problem. I just >>>>> read the instructions provided by the platform maintainer, and all >>>>> is well. I'm also quite happy to use a VMMakerTool that spits out >>>>> the sources for my specific platform. But if you want to produce >>>>> repeatable builds across a range of platforms, you are dealing with >>>>> a different problem. >>>>> >>>>> The Cog branch deals with this by: >>>>> 1) Have VMMaker always generate all the sources for all platforms. >>>>> 2) Use repeatable build scripts or configure/make proceedures for >>>>> each platform. >>>>> >>>>> However this does seem to rely on a collection of scripts and >>>>> makefiles that must be maintained for each platform, and for >>>>> Unix/Linux it is also using the old config process (with libtool >>>>> etc) rather than Ian's newer CMake-based system that is currently >>>>> in use for the Unix VM. >>>>> >>>>> In my own experience (limited primarily to building on Linux for >>>>> my own use, as opposed to building and distributing to other users), >>>>> I found that moving to CMake took some getting used to (damn, not >>>>> another $#%@#%#@! build system ;-) but once I got accustomed to it, >>>>> it works as advertised and does a good job of avoiding platform-specific >>>>> problems, such as libtool failing to work for building 32 bit libraries >>>>> on a 64 bit system, to cite a recent example. >>>>> >>>>> So if I were going to attempt to produce a repeatable, cross-platform >>>>> build system, I would be inclined to take the following approach >>>>> long term: >>>>> >>>>> 1) Adopt the Cog approach of generating a single set of source code >>>>> from VMMaker for all platforms (no, that does not mean I want to >>>>> get rid of the current VMMakerTool, but if I wanted to build for >>>>> multiple platforms, it is better to use the Cog approach here). >>>>> >>>>> 2) Update the current Unix CMake to reflect the changes from the >>>>> above (I assume Ian will want to do that). >>>>> >>>>> 3) Figure out how to replace the current build scripts for the >>>>> other platforms with CMake. >>>>> >>>>> 4) Make it all work the same for Cog and the interpreter VM. >>>>> >>>>> To be clear, I do not personally plan to do the above (except >>>>> for #1), but if I needed a cross-platform build system for a range >>>>> of VMs, that is how I would attack the problem. >>>>> >>>>> Just my $0.02, and I suspect that you will be in an excellent position >>>>> to offer your own perspective on this pretty soon ;-) >>>>> >>>>> Dave >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > -- Best regards, Igor Stasenko AKA sig. |
|
|
El 19/12/2010, a las 4:44p.m., Igor Stasenko escribió: > > On 19 December 2010 20:35, Marco Schmidt <[hidden email]> wrote: >> >> I'm using cmake and Xcode (beside Eclipse under Linux and MS VS2008) >> with great success as cross plattform build system. You can generate >> Xcode-project files with cmake -G"Xcode". There is support for cmake >> in the non-cog branch (currently linux only?) >> > OH, that's interesting. (going to try it out) +1 |
|
|
In reply to this post by Igor Stasenko
Have you looked at Xcode Build System Guide: Introduction, Build Phases, where it talks about adding custom steps to the Target build phase, including 'Copy Files', and 'Run Script' build phases. You can also create custom build rules scripts, see Creating a Build Rule Script. Maybe something in there will allow you to do what you want. Ken At 7:48 PM +0100 12/19/10, Igor Stasenko apparently wrote: >David, >i agree that using CMake for building VM is good because it is >cross-platform tool. >So, it is obvious choice for automating building tasks. >But not when you in developing/debugging mode, since you need UI to >see what happens, (don't tell me gdb is all UI i need ;) >That's where integrated dev environments like xcode rocks. > >So, i wonder if its possible to have a cake and eat it too :) > >On 19 December 2010 19:23, David T. Lewis <[hidden email]> wrote: >> >> On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote: >>> >>> On 19 December 2010 18:01, Ken G. Brown <[hidden email]> wrote: >>> > >>> > At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: >>> >> >>> >>i just wonder, how one could force xcode to compile & link only those >>> >>internal plugins, which is listed in >>> >>plugins.int? >>> >> >>> >>This is sorta easy to do using makefiles.. but with xcode.. im lost.. >>> >> >>> >>Any ideas? >>> >> >>> > >>> > Xcode project display has a column with header icon looking like a circle with a dot in it. That column has checkboxes beside the files, checked = include in the build, unchecked = do not include. Files would need to be dragged into your project to be visible. >>> > >>> >>> Thanks, captain obvious :) >>> >>> Now tell me how i call force xcode to automatically do not include >>> some/all .c files into build, based on the contents of >>> plugins.int file ? >>> :) >> >> Hi Igor, >> >> I know next to nothing about xcode, but I would note that we are >> accumulating quite a few different build systems. As an individual >> user building a VM on my own computer, this is no problem. I just >> read the instructions provided by the platform maintainer, and all >> is well. I'm also quite happy to use a VMMakerTool that spits out >> the sources for my specific platform. But if you want to produce >> repeatable builds across a range of platforms, you are dealing with >> a different problem. >> >> The Cog branch deals with this by: >> 1) Have VMMaker always generate all the sources for all platforms. >> 2) Use repeatable build scripts or configure/make proceedures for >> each platform. >> >> However this does seem to rely on a collection of scripts and >> makefiles that must be maintained for each platform, and for >> Unix/Linux it is also using the old config process (with libtool >> etc) rather than Ian's newer CMake-based system that is currently >> in use for the Unix VM. >> >> In my own experience (limited primarily to building on Linux for >> my own use, as opposed to building and distributing to other users), >> I found that moving to CMake took some getting used to (damn, not >> another $#%@#%#@! build system ;-) but once I got accustomed to it, >> it works as advertised and does a good job of avoiding platform-specific >> problems, such as libtool failing to work for building 32 bit libraries >> on a 64 bit system, to cite a recent example. >> >> So if I were going to attempt to produce a repeatable, cross-platform >> build system, I would be inclined to take the following approach >> long term: >> >> 1) Adopt the Cog approach of generating a single set of source code >> from VMMaker for all platforms (no, that does not mean I want to >> get rid of the current VMMakerTool, but if I wanted to build for >> multiple platforms, it is better to use the Cog approach here). >> >> 2) Update the current Unix CMake to reflect the changes from the >> above (I assume Ian will want to do that). >> >> 3) Figure out how to replace the current build scripts for the >> other platforms with CMake. > > >> 4) Make it all work the same for Cog and the interpreter VM. >> >> To be clear, I do not personally plan to do the above (except >> for #1), but if I needed a cross-platform build system for a range >> of VMs, that is how I would attack the problem. >> >> Just my $0.02, and I suspect that you will be in an excellent position >> to offer your own perspective on this pretty soon ;-) >> >> Dave >> >> > > > >-- >Best regards, >Igor Stasenko AKA sig. |
|
|
In reply to this post by Igor Stasenko
On Sun, 19 Dec 2010, Igor Stasenko wrote: > > On 19 December 2010 19:59, Levente Uzonyi <[hidden email]> wrote: >> >> On Sun, 19 Dec 2010, Igor Stasenko wrote: >> >>> >>> David, >>> i agree that using CMake for building VM is good because it is >>> cross-platform tool. >>> So, it is obvious choice for automating building tasks. >>> But not when you in developing/debugging mode, since you need UI to >>> see what happens, (don't tell me gdb is all UI i need ;) >>> That's where integrated dev environments like xcode rocks. >> >> There are free, cross-platform IDE's that support CMake and GDB, like >> Eclipse or NetBeans. So that can be unified too if you really want it to be. >> ;) > > ouch.. > Tried using NetBeans once... on a small C++ project.. > Just two words: crawls, crashes. These were just examples. Btw I used to use these tools and they were pretty good. And keep in mind that they are getting better and better, so what you've experienced 1-2 years ago are probably fixed by now. > I can't imagine what will happen with it if you pass interp.c to it. > xcode btw, also feels a bit shocked > when it opens interp.c :) (takes around a minute for it, when you > happily watching the rolling rainbow disc) Extracting all the static information takes a lot of time. Levente > >> >> >> Levente >> >>> >>> So, i wonder if its possible to have a cake and eat it too :) >>> >>> On 19 December 2010 19:23, David T. Lewis <[hidden email]> wrote: >>>> >>>> On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote: >>>>> >>>>> On 19 December 2010 18:01, Ken G. Brown <[hidden email]> wrote: >>>>>> >>>>>> At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote: >>>>>>> >>>>>>> i just wonder, how one could force xcode to compile & link only those >>>>>>> internal plugins, which is listed in >>>>>>> plugins.int? >>>>>>> >>>>>>> This is sorta easy to do using makefiles.. but with xcode.. im lost.. >>>>>>> >>>>>>> Any ideas? >>>>>>> >>>>>> >>>>>> Xcode project display has a column with header icon looking like a >>>>>> circle with a dot in it. That column has checkboxes beside the files, >>>>>> checked = include in the build, unchecked = do not include. Files would need >>>>>> to be dragged into your project to be visible. >>>>>> >>>>> >>>>> Thanks, captain obvious :) >>>>> >>>>> Now tell me how i call force xcode to automatically do not include >>>>> some/all .c files into build, based on the contents of >>>>> plugins.int file ? >>>>> :) >>>> >>>> Hi Igor, >>>> >>>> I know next to nothing about xcode, but I would note that we are >>>> accumulating quite a few different build systems. As an individual >>>> user building a VM on my own computer, this is no problem. I just >>>> read the instructions provided by the platform maintainer, and all >>>> is well. I'm also quite happy to use a VMMakerTool that spits out >>>> the sources for my specific platform. But if you want to produce >>>> repeatable builds across a range of platforms, you are dealing with >>>> a different problem. >>>> >>>> The Cog branch deals with this by: >>>> 1) Have VMMaker always generate all the sources for all platforms. >>>> 2) Use repeatable build scripts or configure/make proceedures for >>>> each platform. >>>> >>>> However this does seem to rely on a collection of scripts and >>>> makefiles that must be maintained for each platform, and for >>>> Unix/Linux it is also using the old config process (with libtool >>>> etc) rather than Ian's newer CMake-based system that is currently >>>> in use for the Unix VM. >>>> >>>> In my own experience (limited primarily to building on Linux for >>>> my own use, as opposed to building and distributing to other users), >>>> I found that moving to CMake took some getting used to (damn, not >>>> another $#%@#%#@! build system ;-) but once I got accustomed to it, >>>> it works as advertised and does a good job of avoiding platform-specific >>>> problems, such as libtool failing to work for building 32 bit libraries >>>> on a 64 bit system, to cite a recent example. >>>> >>>> So if I were going to attempt to produce a repeatable, cross-platform >>>> build system, I would be inclined to take the following approach >>>> long term: >>>> >>>> 1) Adopt the Cog approach of generating a single set of source code >>>> from VMMaker for all platforms (no, that does not mean I want to >>>> get rid of the current VMMakerTool, but if I wanted to build for >>>> multiple platforms, it is better to use the Cog approach here). >>>> >>>> 2) Update the current Unix CMake to reflect the changes from the >>>> above (I assume Ian will want to do that). >>>> >>>> 3) Figure out how to replace the current build scripts for the >>>> other platforms with CMake. >>>> >>>> 4) Make it all work the same for Cog and the interpreter VM. >>>> >>>> To be clear, I do not personally plan to do the above (except >>>> for #1), but if I needed a cross-platform build system for a range >>>> of VMs, that is how I would attack the problem. >>>> >>>> Just my $0.02, and I suspect that you will be in an excellent position >>>> to offer your own perspective on this pretty soon ;-) >>>> >>>> Dave >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
|
|
In reply to this post by Igor Stasenko
On Sun, Dec 19, 2010 at 08:44:34PM +0100, Igor Stasenko wrote: > > On 19 December 2010 20:35, Marco Schmidt <[hidden email]> wrote: > > > > I'm using cmake and Xcode (beside Eclipse under Linux and MS VS2008) > > with great success as cross plattform build system. You can generate > > Xcode-project files with cmake -G"Xcode". There is support for cmake > > in the non-cog branch (currently linux only?) > > > OH, that's interesting. (going to try it out) Geoffroy Couprie extended this for Windows also, see the thread at: http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html Dave |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |