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 lewis@mail.msen.com wrote:

On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote:

...

On 19 December 2010 18:01, Ken G. Brown kbrown@mac.com 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

On 19 December 2010 19:59, Levente Uzonyi leves@elte.hu 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 lewis@mail.msen.com wrote:

...

On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote:

...

On 19 December 2010 18:01, Ken G. Brown kbrown@mac.com 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 19 December 2010 20:35, Marco Schmidt Marco.Schmidt@taugamma.de 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 siguctua@gmail.com:

...

On 19 December 2010 19:59, Levente Uzonyi leves@elte.hu 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 lewis@mail.msen.com wrote:

...

On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote:

...

On 19 December 2010 18:01, Ken G. Brown kbrown@mac.com 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.

On Sun, Dec 19, 2010 at 08:44:34PM +0100, Igor Stasenko wrote:

On 19 December 2010 20:35, Marco Schmidt Marco.Schmidt@taugamma.de 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

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

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 lewis@mail.msen.com wrote:

...

On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote:

...

On 19 December 2010 18:01, Ken G. Brown kbrown@mac.com 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.