I would like to get more feedback regarding the summary I posted a week ago. Reverse engineering configure to get configure.ac has meant a lot of work (see my progress attached) yet I still believe this step is crucial to tidy up our build system and add new platforms more easily, by adding more and *better* tests to configure.ac.

Please let me know if there's any interest on this or whether you want to follow a different approach.

On Sat, Oct 8, 2016 at 12:27 AM, Gerardo Santana Gómez Garrido < gerardo.santana@gmail.com> wrote:

To summarize it:

1. use simple, hand tailored, GNU Makefiles for building
2. generate and distribute a config.h once per platform
3. re-generate them only when a new platform is added or a current

platform has had significant changes

For #3 to happen we need a configure script to do it. New platforms or changes to current ones will certainly mean adding tests to the configure script and so we also need configure.ac, for maintaining it.

Sadly, it seems that the configure script was being generated and checked into the source tree without the corresponding configure.ac. FYI, I'm working on reverse engineering it to get the original configure.ac. After that it will be easy to move to where we want to be.

On Wed, Oct 5, 2016 at 8:38 PM, Gerardo Santana Gómez Garrido < gerardo.santana@gmail.com> wrote:

...

Yes, makes sense. Thanks. I will work on simplify it, based on your directives.

On Tue, Oct 4, 2016 at 2:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:

...

Hi Gerardo,

On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido < gerardo.santana@gmail.com> wrote:

...

Yes, energy and will.

Actually I would like to keep autoconf. I found out some duplicated code in the build.* directories that could probably be solved by using the autotools properly.

Are you strongly opposed to using autotools? May I try to make it work?

No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this):

1. The correct realm for autoconf is in determining what facilities the

platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h.

2. the VM is to be configured from config.h (which informs us as to what

third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries).

So the build scheme we're trying to move towards is

a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build

b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs

Does that make sense? For me this is very important. See

http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2 016-February/119002.html

and this is from a Squeak Oversight Board discussion before we moved to githug:

"It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))."

...

On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda eliot.miranda@gmail.com wrote:

...

Hi Gerardo,

welcome!

On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido < gerardo.santana@gmail.com> wrote:

...

Hi Eliot,

what is the proper way to ask questions regarding building Clog?

I just found that in opensmalltalk-vm/platforms/unix/config, configure is not in sync with configure.ac

It may or may not be. Currently I can only reliably run make to generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure. We hope to eliminate configure soon and use a makefile style similar to the Mac and Windows platforms. Do you have energy to contribute to this?

...

Thanks in advance.

P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for a better way to do it.

-- Gerardo Santana

_,,,^..^,,,_ best, Eliot

-- Gerardo Santana

-- _,,,^..^,,,_ best, Eliot

-- Gerardo Santana

-- Gerardo Santana

On 16 Oct 2016, at 20:03, Ben Coman btc@openInWorld.com wrote:

On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

I would like to get more feedback regarding the summary I posted a week ago. Reverse engineering configure to get configure.ac has meant a lot of work (see my progress attached) yet I still believe this step is crucial to tidy up our build system and add new platforms more easily, by adding more and *better* tests to configure.ac.

Please let me know if there's any interest on this or whether you want to follow a different approach.

On Sat, Oct 8, 2016 at 12:27 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

To summarize it:

1. use simple, hand tailored, GNU Makefiles for building
2. generate and distribute a config.h once per platform
3. re-generate them only when a new platform is added or a current platform has had significant changes

For #3 to happen we need a configure script to do it. New platforms or changes to current ones will certainly mean adding tests to the configure script and so we also need configure.ac, for maintaining it.

Sadly, it seems that the configure script was being generated and checked into the source tree without the corresponding configure.ac. FYI, I'm working on reverse engineering it to get the original configure.ac. After that it will be easy to move to where we want to be.

On Wed, Oct 5, 2016 at 8:38 PM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

Yes, makes sense. Thanks. I will work on simplify it, based on your directives.

On Tue, Oct 4, 2016 at 2:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:

...

Hi Gerardo,

On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

Yes, energy and will.

Actually I would like to keep autoconf. I found out some duplicated code in the build.* directories that could probably be solved by using the autotools properly.

Are you strongly opposed to using autotools? May I try to make it work?

No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this):

1. The correct realm for autoconf is in determining what facilities the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h.

2. the VM is to be configured from config.h (which informs us as to what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries).

So the build scheme we're trying to move towards is

a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build

b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs

Does that make sense? For me this is very important. See

http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/119...

and this is from a Squeak Oversight Board discussion before we moved to githug:

"It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))."

Is the CMake approach certain, or yet to be proven? Maybe CMake fits in better than autoconf with the third party libs used by Pharo ?

...

From my naive reading CMake seems a better cross platform choice than

autoconf, but it seems that CMake can't separate out generating just a config.h file from generating the build makefiles, a part that seems not wanted. Does anyone know any different? I've signed up to the CMake mail list to try to clarify this.

On the flip side, most of the stuff I read about autoconf is that it is very unix based and not suited for cross-platform with native MSWindows MSVC. Except an enabler might be CCCL, a gcc compatibility wrapper for the MSVC command-line.... https://github.com/swig/cccl#autotools-and-msvc https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-unde...

What is the future of (IIUC) Pharo's dynamic generation of Cmake files?

in my talk with Eliot, config.h (named cogConfig.h) generation will be moved to one or the other, the one that is easier. There was not a “use this” decision. today, I’m more closer to the opinion of using autoconf instead cmake. Main reason is that we already use autoconf for linux so why add yet-another-tool?

anyway, that’s what I have from my side. Not squeak board but pharo board :)

Esteban

...

...

...

...

...

On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda eliot.miranda@gmail.com wrote: > > Hi Gerardo, > > welcome! > > On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote: >> >> Hi Eliot, >> >> what is the proper way to ask questions regarding building Clog? >> >> I just found that in opensmalltalk-vm/platforms/unix/config, configure is not in sync with configure.ac

I guess this observation comes from generating configure from configure.ac and finding a difference with the committed configure.

But I see the history date on these files seems in sync https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix... https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix...

so maybe its down to different environments?

I see your version on the right here... https://www.diffchecker.com/jAQEeQOn (valid 1 month only) has this different... AC_DEFUN([AC_ICONV], [ AC_CHECK_FUNC(_dyld_present,[],[ AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) ]) if test $ac_cv_iconv = yes; then LIBS="$LIBS -liconv" fi] )])

which I find in... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm... which is included by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/co... which seems referenced by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/co... but I don't really know how they all fit together.

btw Eliot, I see the following... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/do... describes running configure, but I wonder how much of that from 2010 is still relevant today?

In fact I learnt something new in that doc, reading... "by running the config.status script ... is much faster than running configure all over again. (In fact, make should detect any changes to the plugin configuration and re-run config.status for you automatically.) Note: `configure' doesn't actually create any files. The last thing it does is run `config.status' to create the configured files in blddir from the corresponding file.ins in the unix/config directory.

...

...

...

...

...

> > > It may or may not be. Currently I can only reliably run make to generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure.

Eliot, How do you determine its an invalid configure file? I just ran 'make' in platforms/unix/config without error, although the diff lines is 40k.

...

...

...

...

...

> We hope to eliminate configure soon and use a makefile style similar to the Mac and Windows platforms. Do you have energy to contribute to this? > >> >> >> Thanks in advance. >> >> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for a better way to do it.

On 16 Oct 2016, at 20:33, Tobias Pape Das.Linux@gmx.de wrote:

On 16.10.2016, at 20:27, Esteban Lorenzano <estebanlm@gmail.com mailto:estebanlm@gmail.com> wrote:

...

...

On 16 Oct 2016, at 20:03, Ben Coman btc@openInWorld.com wrote:

On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

I would like to get more feedback regarding the summary I posted a week ago. Reverse engineering configure to get configure.ac has meant a lot of work (see my progress attached) yet I still believe this step is crucial to tidy up our build system and add new platforms more easily, by adding more and *better* tests to configure.ac.

Please let me know if there's any interest on this or whether you want to follow a different approach.

On Sat, Oct 8, 2016 at 12:27 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

To summarize it:

1. use simple, hand tailored, GNU Makefiles for building
2. generate and distribute a config.h once per platform
3. re-generate them only when a new platform is added or a current platform has had significant changes

For #3 to happen we need a configure script to do it. New platforms or changes to current ones will certainly mean adding tests to the configure script and so we also need configure.ac, for maintaining it.

Sadly, it seems that the configure script was being generated and checked into the source tree without the corresponding configure.ac. FYI, I'm working on reverse engineering it to get the original configure.ac. After that it will be easy to move to where we want to be.

On Wed, Oct 5, 2016 at 8:38 PM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

Yes, makes sense. Thanks. I will work on simplify it, based on your directives.

On Tue, Oct 4, 2016 at 2:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote: > > Hi Gerardo, > > On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote: >> >> Yes, energy and will. >> >> Actually I would like to keep autoconf. I found out some duplicated code in the build.* directories that could probably be solved by using the autotools properly. >> >> Are you strongly opposed to using autotools? May I try to make it work? > > > No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this): > > 1. The correct realm for autoconf is in determining what facilities the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h. > > 2. the VM is to be configured from config.h (which informs us as to what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries). > > So the build scheme we're trying to move towards is > > a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build > > b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs > > Does that make sense? For me this is very important. See > > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/119... > > and this is from a Squeak Oversight Board discussion before we moved to githug: > > "It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))."

Is the CMake approach certain, or yet to be proven? Maybe CMake fits in better than autoconf with the third party libs used by Pharo ?

...

From my naive reading CMake seems a better cross platform choice than

autoconf, but it seems that CMake can't separate out generating just a config.h file from generating the build makefiles, a part that seems not wanted. Does anyone know any different? I've signed up to the CMake mail list to try to clarify this.

On the flip side, most of the stuff I read about autoconf is that it is very unix based and not suited for cross-platform with native MSWindows MSVC. Except an enabler might be CCCL, a gcc compatibility wrapper for the MSVC command-line.... https://github.com/swig/cccl#autotools-and-msvc https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-unde...

What is the future of (IIUC) Pharo's dynamic generation of Cmake files?

in my talk with Eliot, config.h (named cogConfig.h) generation will be moved to one or the other, the one that is easier. There was not a “use this” decision. today, I’m more closer to the opinion of using autoconf instead cmake. Main reason is that we already use autoconf for linux so why add yet-another-tool?

Sorry, but CMake has been used since 2006 for the Interpreter VM on Linux replacing Autoconf there… CMake is much less convoluted than Autoconf.

Well, the VM we use uses autoconf for building linux, I didn’t see any CMake. In Pharo branch, we use CMake, so *in theory* I should prefer CMake over Autoconf. Now… I'm also a fan of keeping things as simple as possible, that’s why I would think carefully before introducing a new tool… (I do not know interpreter side).

And CMake being less convoluted than Autoconf… well, I’m not so sure, I suffered a lot both of them :)

Esteban

...

anyway, that’s what I have from my side. Not squeak board but pharo board :)

Esteban

...

...

...

...

> > > > >> >> On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda eliot.miranda@gmail.com wrote: >>> >>> Hi Gerardo, >>> >>> welcome! >>> >>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote: >>>> >>>> Hi Eliot, >>>> >>>> what is the proper way to ask questions regarding building Clog? >>>> >>>> I just found that in opensmalltalk-vm/platforms/unix/config, configure is not in sync with configure.ac

I guess this observation comes from generating configure from configure.ac and finding a difference with the committed configure.

But I see the history date on these files seems in sync https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix... https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix...

so maybe its down to different environments?

I see your version on the right here... https://www.diffchecker.com/jAQEeQOn (valid 1 month only) has this different... AC_DEFUN([AC_ICONV], [ AC_CHECK_FUNC(_dyld_present,[],[ AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) ]) if test $ac_cv_iconv = yes; then LIBS="$LIBS -liconv" fi] )])

which I find in... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm... which is included by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/co... which seems referenced by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/co... but I don't really know how they all fit together.

btw Eliot, I see the following... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/do... describes running configure, but I wonder how much of that from 2010 is still relevant today?

In fact I learnt something new in that doc, reading... "by running the config.status script ... is much faster than running configure all over again. (In fact, make should detect any changes to the plugin configuration and re-run config.status for you automatically.) Note: `configure' doesn't actually create any files. The last thing it does is run `config.status' to create the configured files in blddir from the corresponding file.ins in the unix/config directory.

...

...

...

>>> >>> >>> It may or may not be. Currently I can only reliably run make to generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure.

Eliot, How do you determine its an invalid configure file? I just ran 'make' in platforms/unix/config without error, although the diff lines is 40k.

...

...

...

>>> We hope to eliminate configure soon and use a makefile style similar to the Mac and Windows platforms. Do you have energy to contribute to this? >>> >>>> >>>> >>>> Thanks in advance. >>>> >>>> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for a better way to do it.

I was able to build on OSX, Win, and Linux with CMake tools.

Makes much more sense than autoconf/make crap.

Let's not go there.

Phil

On Sun, Oct 16, 2016 at 8:41 PM, Esteban Lorenzano estebanlm@gmail.com wrote:

On 16 Oct 2016, at 20:33, Tobias Pape Das.Linux@gmx.de wrote:

On 16.10.2016, at 20:27, Esteban Lorenzano estebanlm@gmail.com wrote:

On 16 Oct 2016, at 20:03, Ben Coman btc@openInWorld.com wrote:

On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

I would like to get more feedback regarding the summary I posted a week ago. Reverse engineering configure to get configure.ac has meant a lot of work (see my progress attached) yet I still believe this step is crucial to tidy up our build system and add new platforms more easily, by adding more and *better* tests to configure.ac.

Please let me know if there's any interest on this or whether you want to follow a different approach.

On Sat, Oct 8, 2016 at 12:27 AM, Gerardo Santana Gómez Garrido < gerardo.santana@gmail.com> wrote:

To summarize it:

1. use simple, hand tailored, GNU Makefiles for building
2. generate and distribute a config.h once per platform
3. re-generate them only when a new platform is added or a current

platform has had significant changes

For #3 to happen we need a configure script to do it. New platforms or changes to current ones will certainly mean adding tests to the configure script and so we also need configure.ac, for maintaining it.

Sadly, it seems that the configure script was being generated and checked into the source tree without the corresponding configure.ac. FYI, I'm working on reverse engineering it to get the original configure.ac. After that it will be easy to move to where we want to be.

On Wed, Oct 5, 2016 at 8:38 PM, Gerardo Santana Gómez Garrido < gerardo.santana@gmail.com> wrote:

Yes, makes sense. Thanks. I will work on simplify it, based on your directives.

On Tue, Oct 4, 2016 at 2:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:

Hi Gerardo,

On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido < gerardo.santana@gmail.com> wrote:

Yes, energy and will.

Actually I would like to keep autoconf. I found out some duplicated code in the build.* directories that could probably be solved by using the autotools properly.

Are you strongly opposed to using autotools? May I try to make it work?

No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this):

1. The correct realm for autoconf is in determining what facilities the

platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h.

2. the VM is to be configured from config.h (which informs us as to what

third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries).

So the build scheme we're trying to move towards is

a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build

b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs

Does that make sense? For me this is very important. See

http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/ 119002.html

and this is from a Squeak Oversight Board discussion before we moved to githug:

"It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))."

Is the CMake approach certain, or yet to be proven? Maybe CMake fits in better than autoconf with the third party libs used by Pharo ?

From my naive reading CMake seems a better cross platform choice than

autoconf, but it seems that CMake can't separate out generating just a config.h file from generating the build makefiles, a part that seems not wanted. Does anyone know any different? I've signed up to the CMake mail list to try to clarify this.

On the flip side, most of the stuff I read about autoconf is that it is very unix based and not suited for cross-platform with native MSWindows MSVC. Except an enabler might be CCCL, a gcc compatibility wrapper for the MSVC command-line.... https://github.com/swig/cccl#autotools-and-msvc https://folti.blogs.balabit.com/2009/08/compiling- autoconfmake-projects-under-msvc-part-one/

What is the future of (IIUC) Pharo's dynamic generation of Cmake files?

in my talk with Eliot, config.h (named cogConfig.h) generation will be moved to one or the other, the one that is easier. There was not a “use this” decision. today, I’m more closer to the opinion of using autoconf instead cmake. Main reason is that we already use autoconf for linux so why add yet-another-tool?

Sorry, but CMake has been used since 2006 for the Interpreter VM on Linux replacing Autoconf there… CMake is much less convoluted than Autoconf.

Well, the VM we use uses autoconf for building linux, I didn’t see any CMake. In Pharo branch, we use CMake, so *in theory* I should prefer CMake over Autoconf. Now… I'm also a fan of keeping things as simple as possible, that’s why I would think carefully before introducing a new tool… (I do not know interpreter side).

And CMake being less convoluted than Autoconf… well, I’m not so sure, I suffered a lot both of them :)

Esteban

anyway, that’s what I have from my side. Not squeak board but pharo board :)

Esteban

On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda eliot.miranda@gmail.com wrote:

Hi Gerardo,

welcome!

On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido < gerardo.santana@gmail.com> wrote:

Hi Eliot,

what is the proper way to ask questions regarding building Clog?

I just found that in opensmalltalk-vm/platforms/unix/config, configure is not in sync with configure.ac

I guess this observation comes from generating configure from configure.ac and finding a difference with the committed configure.

But I see the history date on these files seems in sync https://github.com/OpenSmalltalk/opensmalltalk- vm/commits/Cog/platforms/unix/config/configure.ac https://github.com/OpenSmalltalk/opensmalltalk- vm/commits/Cog/platforms/unix/config/configure

so maybe its down to different environments?

I see your version on the right here... https://www.diffchecker.com/jAQEeQOn (valid 1 month only) has this different... AC_DEFUN([AC_ICONV], [ AC_CHECK_FUNC(_dyld_present,[],[ AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) ]) if test $ac_cv_iconv = yes; then LIBS="$LIBS -liconv" fi] )])

which I find in... https://github.com/OpenSmalltalk/opensmalltalk- vm/blob/Cog/platforms/unix/vm/acinclude.m4 which is included by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/ config/aclocal.m4 which seems referenced by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/ config/Makefile but I don't really know how they all fit together.

btw Eliot, I see the following... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/ doc/HowToBuildFromSource.txt describes running configure, but I wonder how much of that from 2010 is still relevant today?

In fact I learnt something new in that doc, reading... "by running the config.status script ... is much faster than running configure all over again. (In fact, make should detect any changes to the plugin configuration and re-run config.status for you automatically.) Note: `configure' doesn't actually create any files. The last thing it does is run `config.status' to create the configured files in blddir from the corresponding file.ins in the unix/config directory.

It may or may not be. Currently I can only reliably run make to generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure.

Eliot, How do you determine its an invalid configure file? I just ran 'make' in platforms/unix/config without error, although the diff lines is 40k.

We hope to eliminate configure soon and use a makefile style similar to the Mac and Windows platforms. Do you have energy to contribute to this?

Thanks in advance.

P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for a better way to do it.

On 16 Oct 2016, at 22:30, Tobias Pape Das.Linux@gmx.de wrote:

I think we should defer this discussion again until we all are comfortable with the Gihtub workflow for opensmalltalk-vm

:)

so far there was not a discussion, just an exchange of opinions ;)

Esteban

Best regards -Tobiad On 16.10.2016, at 21:35, phil@highoctane.be wrote:

...

I was able to build on OSX, Win, and Linux with CMake tools.

Makes much more sense than autoconf/make crap.

Let's not go there.

Phil

On Sun, Oct 16, 2016 at 8:41 PM, Esteban Lorenzano estebanlm@gmail.com wrote:

...

On 16 Oct 2016, at 20:33, Tobias Pape Das.Linux@gmx.de wrote:

On 16.10.2016, at 20:27, Esteban Lorenzano estebanlm@gmail.com wrote:

...

...

On 16 Oct 2016, at 20:03, Ben Coman btc@openInWorld.com wrote:

On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

I would like to get more feedback regarding the summary I posted a week ago. Reverse engineering configure to get configure.ac has meant a lot of work (see my progress attached) yet I still believe this step is crucial to tidy up our build system and add new platforms more easily, by adding more and *better* tests to configure.ac.

Please let me know if there's any interest on this or whether you want to follow a different approach.

On Sat, Oct 8, 2016 at 12:27 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote: > > To summarize it: > > 1. use simple, hand tailored, GNU Makefiles for building > 2. generate and distribute a config.h once per platform > 3. re-generate them only when a new platform is added or a current platform has had significant changes > > For #3 to happen we need a configure script to do it. New platforms or changes to current ones will certainly mean adding tests to the configure script and so we also need configure.ac, for maintaining it. > > Sadly, it seems that the configure script was being generated and checked into the source tree without the corresponding configure.ac. FYI, I'm working on reverse engineering it to get the original configure.ac. After that it will be easy to move to where we want to be. > > > On Wed, Oct 5, 2016 at 8:38 PM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote: >> >> Yes, makes sense. Thanks. I will work on simplify it, based on your directives. >> >> On Tue, Oct 4, 2016 at 2:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote: >>> >>> Hi Gerardo, >>> >>> On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote: >>>> >>>> Yes, energy and will. >>>> >>>> Actually I would like to keep autoconf. I found out some duplicated code in the build.* directories that could probably be solved by using the autotools properly. >>>> >>>> Are you strongly opposed to using autotools? May I try to make it work? >>> >>> >>> No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this): >>> >>> 1. The correct realm for autoconf is in determining what facilities the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h. >>> >>> 2. the VM is to be configured from config.h (which informs us as to what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries). >>> >>> So the build scheme we're trying to move towards is >>> >>> a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build >>> >>> b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs >>> >>> Does that make sense? For me this is very important. See >>> >>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/119... >>> >>> and this is from a Squeak Oversight Board discussion before we moved to githug: >>> >>> "It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))."

Is the CMake approach certain, or yet to be proven? Maybe CMake fits in better than autoconf with the third party libs used by Pharo ?

...

From my naive reading CMake seems a better cross platform choice than

autoconf, but it seems that CMake can't separate out generating just a config.h file from generating the build makefiles, a part that seems not wanted. Does anyone know any different? I've signed up to the CMake mail list to try to clarify this.

On the flip side, most of the stuff I read about autoconf is that it is very unix based and not suited for cross-platform with native MSWindows MSVC. Except an enabler might be CCCL, a gcc compatibility wrapper for the MSVC command-line.... https://github.com/swig/cccl#autotools-and-msvc https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-unde...

What is the future of (IIUC) Pharo's dynamic generation of Cmake files?

in my talk with Eliot, config.h (named cogConfig.h) generation will be moved to one or the other, the one that is easier. There was not a “use this” decision. today, I’m more closer to the opinion of using autoconf instead cmake. Main reason is that we already use autoconf for linux so why add yet-another-tool?

Sorry, but CMake has been used since 2006 for the Interpreter VM on Linux replacing Autoconf there… CMake is much less convoluted than Autoconf.

Well, the VM we use uses autoconf for building linux, I didn’t see any CMake. In Pharo branch, we use CMake, so *in theory* I should prefer CMake over Autoconf. Now… I'm also a fan of keeping things as simple as possible, that’s why I would think carefully before introducing a new tool… (I do not know interpreter side).

And CMake being less convoluted than Autoconf… well, I’m not so sure, I suffered a lot both of them :)

Esteban

...

...

anyway, that’s what I have from my side. Not squeak board but pharo board :)

Esteban

...

...

>>> >>> >>> >>> >>>> >>>> On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda eliot.miranda@gmail.com wrote: >>>>> >>>>> Hi Gerardo, >>>>> >>>>> welcome! >>>>> >>>>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote: >>>>>> >>>>>> Hi Eliot, >>>>>> >>>>>> what is the proper way to ask questions regarding building Clog? >>>>>> >>>>>> I just found that in opensmalltalk-vm/platforms/unix/config, configure is not in sync with configure.ac

I guess this observation comes from generating configure from configure.ac and finding a difference with the committed configure.

But I see the history date on these files seems in sync https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix... https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix...

so maybe its down to different environments?

I see your version on the right here... https://www.diffchecker.com/jAQEeQOn (valid 1 month only) has this different... AC_DEFUN([AC_ICONV], [ AC_CHECK_FUNC(_dyld_present,[],[ AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) ]) if test $ac_cv_iconv = yes; then LIBS="$LIBS -liconv" fi] )])

which I find in... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm... which is included by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/co... which seems referenced by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/co... but I don't really know how they all fit together.

btw Eliot, I see the following... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/do... describes running configure, but I wonder how much of that from 2010 is still relevant today?

In fact I learnt something new in that doc, reading... "by running the config.status script ... is much faster than running configure all over again. (In fact, make should detect any changes to the plugin configuration and re-run config.status for you automatically.) Note: `configure' doesn't actually create any files. The last thing it does is run `config.status' to create the configured files in blddir from the corresponding file.ins in the unix/config directory.

...

>>>>> >>>>> >>>>> It may or may not be. Currently I can only reliably run make to generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure.

Eliot, How do you determine its an invalid configure file? I just ran 'make' in platforms/unix/config without error, although the diff lines is 40k.

...

>>>>> We hope to eliminate configure soon and use a makefile style similar to the Mac and Windows platforms. Do you have energy to contribute to this? >>>>> >>>>>> >>>>>> >>>>>> Thanks in advance. >>>>>> >>>>>> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for a better way to do it.

On 17 Oct 2016, at 02:07, Ben Coman btc@openInWorld.com wrote:

Phil, Could you outline the steps. Are you doing something other than this... https://github.com/pharo-project/pharo-vm https://github.com/pharo-project/pharo-vm

I think he is talking “in general”, not about the VM in particular.

Esteban

(there you go, with content stripped as Tim like :P)

On Mon, Oct 17, 2016 at 3:31 PM, phil@highoctane.be phil@highoctane.be wrote:

On Mon, Oct 17, 2016 at 8:59 AM, Esteban Lorenzano estebanlm@gmail.com wrote:

...

On 17 Oct 2016, at 02:07, Ben Coman btc@openInWorld.com wrote:

Phil, Could you outline the steps. Are you doing something other than this... https://github.com/pharo-project/pharo-vm

I think he is talking “in general”, not about the VM in particular.

In general. But also about the VM since I wanted to build it for OSX/Win/Linux and CMake + the image code supporting it, while initially a royal PITA (version had to be correct etc) proved to be very useful for a lot of things because it was all logical, variables could be set nicely etc. The CMake UI also allows to detect for a number of crappy mistakes, so, a godsend.

It can also generate XCode project files, which is very useful.

autoconf and makefiles, no thanks.

The image side CMake support looks great to me, better than the VMMaker green UI, which well, let's keep it at that.

It also working nice with a CI server, so why use stoneage tooling when you have a more modern one available?

Learn the damn CMake and profit. We want a great VM, let's use great tools.

A lot of the stuff I read make CMake seem much better, but actually it seems slow - particularly "rebuild leaf" for the 4-level 1112 files ... http://www.kaizou.org/2016/09/build-benchmark-large-c-project.html

I see... $ cd opensmalltalk-vm $ find . -name "*.c" | wc -l #==> 2128 $ find . -name "*.h" | wc -l #==> 1769 but I guess typically we're not building everything, more like... $ find platforms/unix -name "*.c" | wc -l #==> 71 $ find platforms/unix -name "*.h" | wc -l #==> 39 $ find spursrc -name "*.c" | wc -l #==> 6 $ find spursrc -name "*.h" | wc -l #==> 6 which is more in the ballpark of 3-level 100 files.

I found "Recursive Make Considered Harmful" an interesting read... http://aegis.sourceforge.net/auug97.pdf

and why CMake generates recursive Makefiles... https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles...

and how automake can generate non-recursive makefiles... https://www.murrayc.com/permalink/2009/07/24/non-recursive-automake-is-the-b... http://karelzak.blogspot.com.au/2013/02/non-recursive-automake.html

with some annecdotal reports on the benefits on non-recursive makefiles http://stackoverflow.com/questions/559216/what-is-your-experience-with-non-r...

and some tips for handmade Makefiles... http://david.rothlis.net/large-gnu-make/

I bumped into an interesting discussion from a project considering to move from autoconf to Cmake. I was particularly surprised to read that cross-compilation was apparently easier with autoconf than Cmake, since after all CMake is "Cross Platform Make" https://github.com/libjpeg-turbo/libjpeg-turbo/issues/56 and if/when I get back to looking porting to at Xen Rump kernel, cross compilation will be important. Although I remember when doing the tiny Rump tutorial for each of autoconf and Cmake, the latter felt more natural.

Also btw, it seems there is future potential to cross-compile native Windows binaries from Linux with Microsoft donating their debugging Codegen to LLVM, https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-code... http://lists.llvm.org/pipermail/llvm-dev/2015-October/091847.html and some people have previously used the MSVC command-line cl.exe over Wine https://oxygene.sk/2010/09/cross-compiling-with-cmake-and-autotools/ http://www.kegel.com/wine/cl-howto-win7sdk.html http://nullprogram.com/blog/2016/06/13/

CMake's ability to generate different build systems is certainly attractive, but having a common set of make files across all platforms might be just as useful from a support perspective.

I don't really know which way to jump, and sorry I guess none of this discussion helps Gerardo's original query about where best to direct his energy.

cheers -ben

Hi Phil,

On Mon, Oct 17, 2016 at 12:31 AM, phil@highoctane.be phil@highoctane.be wrote:

On Mon, Oct 17, 2016 at 8:59 AM, Esteban Lorenzano estebanlm@gmail.com wrote:

...

On 17 Oct 2016, at 02:07, Ben Coman btc@openInWorld.com wrote:

Phil, Could you outline the steps. Are you doing something other than this... https://github.com/pharo-project/pharo-vm

I think he is talking “in general”, not about the VM in particular.

In general. But also about the VM since I wanted to build it for

OSX/Win/Linux and CMake + the image code supporting it, while initially a royal PITA (version had to be correct etc) proved to be very useful for a lot of things because it was all logical, variables could be set nicely etc. The CMake UI also allows to detect for a number of crappy mistakes, so, a godsend.

It can also generate XCode project files, which is very useful.

autoconf and makefiles, no thanks.

The image side CMake support looks great to me, better than the VMMaker green UI, which well, let's keep it at that.

That tool is not used to generate VM source.

It also working nice with a CI server, so why use stoneage tooling when you have a more modern one available?

Learn the damn CMake and profit. We want a great VM, let's use great tools.

There is agreement amongst the CogVM builders that - we will use cake or autoconf to generate a cogConfig.h that describes the build target platform's capabilities - we will /not/ use either autoconf or cake to generate VM makefiles - we will write linux makefiles in the style of the windows and mac makefiles, all using gmake

We are not using bad tools; cake and autoconf are all useful in their place, but experience has shown that they are not good tools for generating the makefiles we use to build the VM, primarily because they are slow, being painful to run on each make, and because they are higher-order, so figuring out what input to change to achieve a changed output is indirect, and may require a build step (running autoconf/cmake). The makefiles we have for windows and mac are much better; they are fast, running immediately, and direct, their configuration options never depend on rebuilding the make system, only in their configuration files (plugins.int,plugins.ext and attendant platforms/foo/plugins/Makefile files).

HTH

Phil

...

Esteban

(there you go, with content stripped as Tim like :P)

Autoconf crash course ==================

Software developer task --------------------------------

create feature tests (configure.ac) and generate portable shell script (configure) for executing these tests on each platform. Include this script in distribution file for end users that wish to build the software themselves.

configure.ac ---> [autoconf] ---> configure

Optionally, the software developer can include the feature tests ( configure.ac) so that another software developer can add more feature tests for adding support for other platforms.

End user task --------------------

run portable shell script and build.

./configure && make && make install

the configure script is parameterized in a way that enables end users to satisfy its tests (e.g. location of libraries or header files). It can process templates files (e.g. Makefile.in) and generates config.h.

The problem ==========

Today, the configure.ac checked into the repository is *not* the one that generated the configure script. That means that we can't use that configure.ac to generate a new configure script, which in turn means that another developer can't add new feature tests to configure.ac (e.g. for adding support for other platforms.)

For instance, I can't add tests for safer string manipulation functions to compile external ones if needed.

We could have a single source tree for all UNIX-like and GNU/Linux distributions if only we could fix that.

P.S. The current configure script was generated with autoconf 2.59. You will need to use the same autoconf 2.59 to process configure.ac to try to get the same configure script.

On Mon, Oct 17, 2016 at 7:57 PM, Ben Coman btc@openinworld.com wrote:

On Tue, Oct 18, 2016 at 5:31 AM, Eliot Miranda eliot.miranda@gmail.com wrote:

...

Hi Phil,

On Mon, Oct 17, 2016 at 12:31 AM, phil@highoctane.be phil@highoctane.be

wrote:

...

...

On Mon, Oct 17, 2016 at 8:59 AM, Esteban Lorenzano estebanlm@gmail.com

wrote:

...

...

...

On 17 Oct 2016, at 02:07, Ben Coman btc@openInWorld.com wrote:

Phil, Could you outline the steps. Are you doing something other than

this...

...

...

...

https://github.com/pharo-project/pharo-vm

I think he is talking “in general”, not about the VM in particular.

In general. But also about the VM since I wanted to build it for

OSX/Win/Linux and CMake + the image code supporting it, while initially a royal PITA (version had to be correct etc) proved to be very useful for a lot of things because it was all logical, variables could be set nicely etc.

...

...

The CMake UI also allows to detect for a number of crappy mistakes, so,

a godsend.

...

...

It can also generate XCode project files, which is very useful.

autoconf and makefiles, no thanks.

The image side CMake support looks great to me, better than the VMMaker

green UI, which well, let's keep it at that.

...

That tool is not used to generate VM source.

...

It also working nice with a CI server, so why use stoneage tooling when

you have a more modern one available?

...

...

Learn the damn CMake and profit. We want a great VM, let's use great

tools.

...

There is agreement amongst the CogVM builders that

• we will use cake or autoconf to generate a cogConfig.h that describes

the build target platform's capabilities

...

• we will /not/ use either autoconf or cake to generate VM makefiles

Most of my reading indicates the main virtue of CMake over autoconf is the generation of makefiles for different build systems. If we are not doing that, there seems little imperative to move from autoconf to cmake. Autoconf reportedly has slightly better coverage of feature determination.

btw, I found this an interesting insight... http://stackoverflow.com/questions/4071880/autotools-vs-cmake-vs-scons

"An important distinction must be made between who uses the tools. Cmake is a tool that must be used by the user when building the software. The autotools are used to generate a distribution tarball that can be used to build the software using only the standard tools available on any SuS compliant system. In other words, if you are installing software from a tarball that was built using the autotools, you are not using the autotools. On the other hand, if you are installing software that uses Cmake, then you are using Cmake and must have it installed to build the software.

The great majority of users do not need to have the autotools installed on their box. Historically, much confusion has been caused because many developers distribute malformed tarballs that force the user to run autoconf to regenerate the configure script, and this is a packaging error. More confusion has been caused by the fact that most major linux distributions install multiple versions of the autotools, when they should not be installing any of them by default. Even more confusion is caused by developers attempting to use a version control system (eg cvs, git, svn) to distribute their software rather than building tarballs."

cheers -ben

...

• we will write linux makefiles in the style of the windows and mac

makefiles, all using gmake

...

We are not using bad tools; cake and autoconf are all useful in their

place, but experience has shown that they are not good tools for generating the makefiles we use to build the VM, primarily because they are slow, being painful to run on each make, and because they are higher-order, so figuring out what input to change to achieve a changed output is indirect, and may require a build step (running autoconf/cmake). The makefiles we have for windows and mac are much better; they are fast, running immediately, and direct, their configuration options never depend on rebuilding the make system, only in their configuration files (plugins.int,plugins.ext and attendant platforms/foo/plugins/Makefile files).

On Tue, Oct 18, 2016 at 7:49 AM, Tobias Pape Das.Linux@gmx.de wrote:

On 18.10.2016, at 02:57, Ben Coman btc@openinworld.com wrote:

...

On Tue, Oct 18, 2016 at 5:31 AM, Eliot Miranda eliot.miranda@gmail.com

wrote:

...

...

Hi Phil,

On Mon, Oct 17, 2016 at 12:31 AM, phil@highoctane.be <

phil@highoctane.be> wrote:

...

...

...

On Mon, Oct 17, 2016 at 8:59 AM, Esteban Lorenzano <

estebanlm@gmail.com> wrote:

...

...

...

...

On 17 Oct 2016, at 02:07, Ben Coman btc@openInWorld.com wrote:

Phil, Could you outline the steps. Are you doing something other

than this...

...

...

...

...

https://github.com/pharo-project/pharo-vm

I think he is talking “in general”, not about the VM in particular.

In general. But also about the VM since I wanted to build it for

OSX/Win/Linux and CMake + the image code supporting it, while initially a royal PITA (version had to be correct etc) proved to be very useful for a lot of things because it was all logical, variables could be set nicely etc.

...

...

...

The CMake UI also allows to detect for a number of crappy mistakes,

so, a godsend.

...

...

...

It can also generate XCode project files, which is very useful.

autoconf and makefiles, no thanks.

The image side CMake support looks great to me, better than the

VMMaker green UI, which well, let's keep it at that.

...

...

That tool is not used to generate VM source.

...

It also working nice with a CI server, so why use stoneage tooling

when you have a more modern one available?

...

...

...

Learn the damn CMake and profit. We want a great VM, let's use great

tools.

...

...

There is agreement amongst the CogVM builders that

• we will use cake or autoconf to generate a cogConfig.h that describes

the build target platform's capabilities

...

...

• we will /not/ use either autoconf or cake to generate VM makefiles

Most of my reading indicates the main virtue of CMake over autoconf is the generation of makefiles for different build systems.

ACK. it can generate Xcode, VisualStudio, Eclipse… project files, which _tremendously_ eases debugging.

Exactly my point. And also makes it easy to add extra things like additional windows etc to the executable using the proper tools for doing that (e.g. Add Views to the VM in Objective-C with XCode). Plugins also come to mind.

Phil

Dear CogVM builders, what is the IDE you use for development and debugging that works with the "only for config.h" scheme? I'm really interested. (And no, editor+gdb does not count)

Best regards -Tobias

...

If we are not doing that, there seems little imperative to move from autoconf to cmake. Autoconf reportedly has slightly better coverage of feature determination.

btw, I found this an interesting insight... http://stackoverflow.com/questions/4071880/autotools-vs-cmake-vs-scons

"An important distinction must be made between who uses the tools. Cmake is a tool that must be used by the user when building the software. The autotools are used to generate a distribution tarball that can be used to build the software using only the standard tools available on any SuS compliant system. In other words, if you are installing software from a tarball that was built using the autotools, you are not using the autotools. On the other hand, if you are installing software that uses Cmake, then you are using Cmake and must have it installed to build the software.

The great majority of users do not need to have the autotools installed on their box. Historically, much confusion has been caused because many developers distribute malformed tarballs that force the user to run autoconf to regenerate the configure script, and this is a packaging error. More confusion has been caused by the fact that most major linux distributions install multiple versions of the autotools, when they should not be installing any of them by default. Even more confusion is caused by developers attempting to use a version control system (eg cvs, git, svn) to distribute their software rather than building tarballs."

cheers -ben

...

• we will write linux makefiles in the style of the windows and mac

makefiles, all using gmake

...

...

We are not using bad tools; cake and autoconf are all useful in their

place, but experience has shown that they are not good tools for generating the makefiles we use to build the VM, primarily because they are slow, being painful to run on each make, and because they are higher-order, so figuring out what input to change to achieve a changed output is indirect, and may require a build step (running autoconf/cmake). The makefiles we have for windows and mac are much better; they are fast, running immediately, and direct, their configuration options never depend on rebuilding the make system, only in their configuration files (plugins.int,plugins.ext and attendant platforms/foo/plugins/Makefile files).

Tobias,

On Mon, Oct 17, 2016 at 10:49 PM, Tobias Pape Das.Linux@gmx.de wrote:

On 18.10.2016, at 02:57, Ben Coman btc@openinworld.com wrote:

...

On Tue, Oct 18, 2016 at 5:31 AM, Eliot Miranda eliot.miranda@gmail.com

wrote:

...

...

Hi Phil,

On Mon, Oct 17, 2016 at 12:31 AM, phil@highoctane.be <

phil@highoctane.be> wrote:

...

...

...

On Mon, Oct 17, 2016 at 8:59 AM, Esteban Lorenzano <

estebanlm@gmail.com> wrote:

...

...

...

...

On 17 Oct 2016, at 02:07, Ben Coman btc@openInWorld.com wrote:

Phil, Could you outline the steps. Are you doing something other

than this...

...

...

...

...

https://github.com/pharo-project/pharo-vm

I think he is talking “in general”, not about the VM in particular.

In general. But also about the VM since I wanted to build it for

OSX/Win/Linux and CMake + the image code supporting it, while initially a royal PITA (version had to be correct etc) proved to be very useful for a lot of things because it was all logical, variables could be set nicely etc.

...

...

...

The CMake UI also allows to detect for a number of crappy mistakes,

so, a godsend.

...

...

...

It can also generate XCode project files, which is very useful.

autoconf and makefiles, no thanks.

The image side CMake support looks great to me, better than the

VMMaker green UI, which well, let's keep it at that.

...

...

That tool is not used to generate VM source.

...

It also working nice with a CI server, so why use stoneage tooling

when you have a more modern one available?

...

...

...

Learn the damn CMake and profit. We want a great VM, let's use great

tools.

...

...

There is agreement amongst the CogVM builders that

• we will use cake or autoconf to generate a cogConfig.h that describes

the build target platform's capabilities

...

...

• we will /not/ use either autoconf or cake to generate VM makefiles

Most of my reading indicates the main virtue of CMake over autoconf is the generation of makefiles for different build systems.

ACK. it can generate Xcode, VisualStudio, Eclipse… project files, which _tremendously_ eases debugging.

With respect, only in limited genres. Firstly VM debugging is much easier in the simulator than in C. No ammount of navigation through the C code can compensate for the fact that the C is an output language, and not the language of implementation for the key parts of the VM. Second, in debugging the core VM, the support functions that print stack frames and backtraces, objects, references to objects, free lists, etc, etc. It is these that make i possible to debug the VM (as an execution engine, not the support C code), and make project files an inadequate solution. VM state is /not/ the C stack, the locus of attention in a traditional C debugger.

Dear CogVM builders, what is the IDE you use for development and debugging that works with the "only for config.h" scheme? I'm really interested. (And no, editor+gdb does not count)

The simulator, primarily, i.e. Squeak or Pharo. Next, indeed gdb or lldb plus the significant number of debugging functions included in the VM. And it /does/ count.

That said, I have no objection if someone builds a CMake scheme to generate project files for those debugging support C code. I will still council that this effort is wasted when trying to debug the VM as an execution engine; for that one really has to learn the architecture and become familiar with the debug functions (and yes, good documentation would help here, and a lot more than a project file).

What I *do* object to is the use of these project files for a build system. For the last time, I *will not* support such a move. Experience has shown (already 8 yard on Cog) that these get in the way of an efficient build system; they are inflexible and slow. The lean mean gmake files are much much better. So _please_ desist from pushing project build makefiles via CMake. I find this direction antagonising; I have expressed myself clearly on the point, and I have not seen any convincing counterarguments. So can we please settle on the fact that we have agreed to use gmake makefiles for builds. Enough said?

Best regards -Tobias

...

If we are not doing that, there seems little imperative to move from autoconf to cmake. Autoconf reportedly has slightly better coverage of feature determination.

btw, I found this an interesting insight... http://stackoverflow.com/questions/4071880/autotools-vs-cmake-vs-scons

"An important distinction must be made between who uses the tools. Cmake is a tool that must be used by the user when building the software. The autotools are used to generate a distribution tarball that can be used to build the software using only the standard tools available on any SuS compliant system. In other words, if you are installing software from a tarball that was built using the autotools, you are not using the autotools. On the other hand, if you are installing software that uses Cmake, then you are using Cmake and must have it installed to build the software.

The great majority of users do not need to have the autotools installed on their box. Historically, much confusion has been caused because many developers distribute malformed tarballs that force the user to run autoconf to regenerate the configure script, and this is a packaging error. More confusion has been caused by the fact that most major linux distributions install multiple versions of the autotools, when they should not be installing any of them by default. Even more confusion is caused by developers attempting to use a version control system (eg cvs, git, svn) to distribute their software rather than building tarballs."

cheers -ben

...

• we will write linux makefiles in the style of the windows and mac

makefiles, all using gmake

...

...

We are not using bad tools; cake and autoconf are all useful in their

place, but experience has shown that they are not good tools for generating the makefiles we use to build the VM, primarily because they are slow, being painful to run on each make, and because they are higher-order, so figuring out what input to change to achieve a changed output is indirect, and may require a build step (running autoconf/cmake). The makefiles we have for windows and mac are much better; they are fast, running immediately, and direct, their configuration options never depend on rebuilding the make system, only in their configuration files (plugins.int,plugins.ext and attendant platforms/foo/plugins/Makefile files).

On 19.10.2016, at 00:00, Eliot Miranda eliot.miranda@gmail.com wrote:

ACK. it can generate Xcode, VisualStudio, Eclipse… project files, which _tremendously_ eases debugging.

With respect, only in limited genres. Firstly VM debugging is much easier in the simulator than in C. No ammount of navigation through the C code can compensate for the fact that the C is an output language, and not the language of implementation for the key parts of the VM. Second, in debugging the core VM, the support functions that print stack frames and backtraces, objects, references to objects, free lists, etc, etc. It is these that make i possible to debug the VM (as an execution engine, not the support C code), and make project files an inadequate solution. VM state is /not/ the C stack, the locus of attention in a traditional C debugger.

Dear CogVM builders, what is the IDE you use for development and debugging that works with the "only for config.h" scheme? I'm really interested. (And no, editor+gdb does not count)

The simulator, primarily, i.e. Squeak or Pharo. Next, indeed gdb or lldb plus the significant number of debugging functions included in the VM. And it /does/ count.

That said, I have no objection if someone builds a CMake scheme to generate project files for those debugging support C code. I will still council that this effort is wasted when trying to debug the VM as an execution engine; for that one really has to learn the architecture and become familiar with the debug functions (and yes, good documentation would help here, and a lot more than a project file).

What I *do* object to is the use of these project files for a build system. For the last time, I *will not* support such a move. Experience has shown (already 8 yard on Cog) that these get in the way of an efficient build system; they are inflexible and slow. The lean mean gmake files are much much better. So _please_ desist from pushing project build makefiles via CMake. I find this direction antagonising; I have expressed myself clearly on the point, and I have not seen any convincing counterarguments. So can we please settle on the fact that we have agreed to use gmake makefiles for builds.

I still disagree.

I agree that for you as VM/Interpreter/Cog developer, your workflow is useful, lean, and debugging apparently ok.

But seeing that the second PR from the first external contributor is _changing the build system_ speaks volumes. Also, all students I have seen that wanted to play around with the VM were startled by the build process and needed individual help to get going.

But more so, except for the people working on the actual execution engine (Which is probably only you, David, maybe Bert and Tim and Tim), all other contributors typically do not touch or care for the VMMaker part or even the simulator.

It is about the hand-written C (or ObjC) stuff. gdb does not help when SecureTransport does strange things, gdb does not help if I have to debug the ANSI->Wide->UTF8 ordeal on windows.

It took me one and a half days to collect all information necessary to make a VisualStudio project that I could use to test Cog on VisualC. Just to discover that somewhere a C file includes a complete other C-file. Collecting all the defines took hours.

I have yet to collect all the files necessary to have a proper Xcode project that helps me debugging.

I do not speak of debugging the interpreter or debugging the JIT. Just the platform relevant files, or the plugins.

We have 114 'mvm' scripts[1], 356 makefiles[2], 121 maker-script[3], and whooping 115 VM-configuration expressed as _directories_[4].

Ain't nobody got time to read this.

There's frequent complaining that too few people help with VM development. I understand and second.

But this is no ecosystem that encourages helping.

Enough said?

You're not gonna change a thing that hurts you, thats ok. But please do not expect people who want to help to do it solely on your terms.

Best regards -Tobias

PS: It would have been lots better to discuss such things over a whisky than over 8-bit ascii. PPS: HTML mail garbles the reply-quotation.

[1] opensmalltalk-vm$ find . -name mvm |wc -l 114 [2] opensmalltalk-vm$ find . -name makefile |wc -l 356 [3] opensmalltalk-vm$ find . -iname make* | wc -l 477 (- 88 makefiles) [4] opensmalltalk-vm$ ls -d1 build.{mac,win}*/*.*.*/ | wc -l 28 opensmalltalk-vm$ ls -d1 build.linux*/*.*.*/build* | wc -l 87

On 19.10.2016, at 15:00, Ben Coman btc@openinworld.com wrote:

Strange I only get find . -iname makefile | wc -l

Sorry, I had actually

find . -iname makefile* | wc -l

Tobias,

On Wed, Oct 19, 2016 at 12:38 AM, Tobias Pape Das.Linux@gmx.de wrote:

On 19.10.2016, at 00:00, Eliot Miranda eliot.miranda@gmail.com wrote:

...

ACK. it can generate Xcode, VisualStudio, Eclipse… project files, which

_tremendously_ eases

...

debugging.

With respect, only in limited genres. Firstly VM debugging is much

easier in the simulator than in C. No ammount of navigation through the C code can compensate for the fact that the C is an output language, and not the language of implementation for the key parts of the VM. Second, in debugging the core VM, the support functions that print stack frames and backtraces, objects, references to objects, free lists, etc, etc. It is these that make i possible to debug the VM (as an execution engine, not the support C code), and make project files an inadequate solution. VM state is /not/ the C stack, the locus of attention in a traditional C debugger.

...

Dear CogVM builders, what is the IDE you use for development and

debugging that works

...

with the "only for config.h" scheme? I'm really interested. (And no, editor+gdb does not count)

The simulator, primarily, i.e. Squeak or Pharo. Next, indeed gdb or

lldb plus the significant number of debugging functions included in the VM. And it /does/ count.

...

That said, I have no objection if someone builds a CMake scheme to

generate project files for those debugging support C code. I will still council that this effort is wasted when trying to debug the VM as an execution engine; for that one really has to learn the architecture and become familiar with the debug functions (and yes, good documentation would help here, and a lot more than a project file).

...

What I *do* object to is the use of these project files for a build

system. For the last time, I *will not* support such a move. Experience has shown (already 8 yard on Cog) that these get in the way of an efficient build system; they are inflexible and slow. The lean mean gmake files are much much better. So _please_ desist from pushing project build makefiles via CMake. I find this direction antagonising; I have expressed myself clearly on the point, and I have not seen any convincing counterarguments. So can we please settle on the fact that we have agreed to use gmake makefiles for builds.

I still disagree.

I agree that for you as VM/Interpreter/Cog developer, your workflow is useful, lean, and debugging apparently ok.

But seeing that the second PR from the first external contributor is _changing the build system_ speaks volumes. Also, all students I have seen that wanted to play around with the VM were startled by the build process and needed individual help to get going.

They are changing the linux autoconf build system. It's broken. I really don't want

But more so, except for the people working on the actual execution engine (Which is probably only you, David, maybe Bert and Tim and Tim), all other contributors typically do not touch or care for the VMMaker part or even the simulator.

Nicolas Cellier (arithmetic)

It is about the hand-written C (or ObjC) stuff. gdb does not help when SecureTransport does strange things, gdb does not help if I have to debug the ANSI->Wide->UTF8 ordeal on windows.

It took me one and a half days to collect all information necessary to make a VisualStudio project that I could use to test Cog on VisualC. Just to discover that somewhere a C file includes a complete other C-file. Collecting all the defines took hours.

So use CMake to generate it. I don't disagree. But /do not/ force me to use CMake to build the VM. I have explained, and I want you to accept, hat the gmake makefile scheme is a very good one.

I have yet to collect all the files necessary to have a proper Xcode project that helps me debugging.

I do not speak of debugging the interpreter or debugging the JIT. Just the platform relevant files, or the plugins.

We have 114 'mvm' scripts[1], 356 makefiles[2], 121 maker-script[3], and whooping 115 VM-configuration expressed as _directories_[4].

Ain't nobody got time to read this.

There's frequent complaining that too few people help with VM development. I understand and second.

But this is no ecosystem that encourages helping.

...

Enough said?

You're not gonna change a thing that hurts you, thats ok. But please do not expect people who want to help to do it solely on your terms.

I'm NOT saying you cannot generate project makefiles. For the LAST TIME, I am saying I will not accept the VM being *built* with a project file.

I'm fed up of repeating myself.

Best regards -Tobias

PS: It would have been lots better to discuss such things over a whisky than over 8-bit ascii.

+1.

PPS: HTML mail garbles the reply-quotation.

[1] opensmalltalk-vm$ find . -name mvm |wc -l 114 [2] opensmalltalk-vm$ find . -name makefile |wc -l 356 [3] opensmalltalk-vm$ find . -iname make* | wc -l 477 (- 88 makefiles) [4] opensmalltalk-vm$ ls -d1 build.{mac,win}*/*.*.*/ | wc -l 28 opensmalltalk-vm$ ls -d1 build.linux*/*.*.*/build* | wc -l 87

On Mon, Oct 17, 2016 at 2:33 AM, Tobias Pape Das.Linux@gmx.de wrote:

On 16.10.2016, at 20:27, Esteban Lorenzano estebanlm@gmail.com wrote:

...

...

On 16 Oct 2016, at 20:03, Ben Coman btc@openInWorld.com wrote:

On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

I would like to get more feedback regarding the summary I posted a week ago. Reverse engineering configure to get configure.ac has meant a lot of work (see my progress attached) yet I still believe this step is crucial to tidy up our build system and add new platforms more easily, by adding more and *better* tests to configure.ac.

Please let me know if there's any interest on this or whether you want to follow a different approach.

On Sat, Oct 8, 2016 at 12:27 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

To summarize it:

1. use simple, hand tailored, GNU Makefiles for building
2. generate and distribute a config.h once per platform
3. re-generate them only when a new platform is added or a current platform has had significant changes

For #3 to happen we need a configure script to do it. New platforms or changes to current ones will certainly mean adding tests to the configure script and so we also need configure.ac, for maintaining it.

Sadly, it seems that the configure script was being generated and checked into the source tree without the corresponding configure.ac. FYI, I'm working on reverse engineering it to get the original configure.ac. After that it will be easy to move to where we want to be.

On Wed, Oct 5, 2016 at 8:38 PM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

Yes, makes sense. Thanks. I will work on simplify it, based on your directives.

On Tue, Oct 4, 2016 at 2:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote: > > Hi Gerardo, > > On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote: >> >> Yes, energy and will. >> >> Actually I would like to keep autoconf. I found out some duplicated code in the build.* directories that could probably be solved by using the autotools properly. >> >> Are you strongly opposed to using autotools? May I try to make it work? > > > No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this): > > 1. The correct realm for autoconf is in determining what facilities the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h. > > 2. the VM is to be configured from config.h (which informs us as to what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries). > > So the build scheme we're trying to move towards is > > a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build > > b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs > > Does that make sense? For me this is very important. See > > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/119... > > and this is from a Squeak Oversight Board discussion before we moved to githug: > > "It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))."

Is the CMake approach certain, or yet to be proven? Maybe CMake fits in better than autoconf with the third party libs used by Pharo ?

...

From my naive reading CMake seems a better cross platform choice than

autoconf, but it seems that CMake can't separate out generating just a config.h file from generating the build makefiles, a part that seems not wanted. Does anyone know any different? I've signed up to the CMake mail list to try to clarify this.

On the flip side, most of the stuff I read about autoconf is that it is very unix based and not suited for cross-platform with native MSWindows MSVC. Except an enabler might be CCCL, a gcc compatibility wrapper for the MSVC command-line.... https://github.com/swig/cccl#autotools-and-msvc https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-unde...

What is the future of (IIUC) Pharo's dynamic generation of Cmake files?

in my talk with Eliot, config.h (named cogConfig.h) generation will be moved to one or the other, the one that is easier. There was not a “use this” decision. today, I’m more closer to the opinion of using autoconf instead cmake. Main reason is that we already use autoconf for linux so why add yet-another-tool?

Sorry, but CMake has been used since 2006 for the Interpreter VM on Linux replacing Autoconf there… CMake is much less convoluted than Autoconf.

...

anyway, that’s what I have from my side. Not squeak board but pharo board :)

Esteban

...

...

...

...

> > > > >> >> On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda eliot.miranda@gmail.com wrote: >>> >>> Hi Gerardo, >>> >>> welcome! >>> >>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote: >>>> >>>> Hi Eliot, >>>> >>>> what is the proper way to ask questions regarding building Clog? >>>> >>>> I just found that in opensmalltalk-vm/platforms/unix/config, configure is not in sync with configure.ac

I guess this observation comes from generating configure from configure.ac and finding a difference with the committed configure.

But I see the history date on these files seems in sync https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix... https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix...

so maybe its down to different environments?

I see your version on the right here... https://www.diffchecker.com/jAQEeQOn (valid 1 month only) has this different... AC_DEFUN([AC_ICONV], [ AC_CHECK_FUNC(_dyld_present,[],[ AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) ]) if test $ac_cv_iconv = yes; then LIBS="$LIBS -liconv" fi] )])

which I find in... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm... which is included by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/co... which seems referenced by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/co... but I don't really know how they all fit together.

btw Eliot, I see the following... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/do... describes running configure, but I wonder how much of that from 2010 is still relevant today?

In fact I learnt something new in that doc, reading... "by running the config.status script ... is much faster than running configure all over again. (In fact, make should detect any changes to the plugin configuration and re-run config.status for you automatically.) Note: `configure' doesn't actually create any files. The last thing it does is run `config.status' to create the configured files in blddir from the corresponding file.ins in the unix/config directory.

...

...

...

>>> >>> >>> It may or may not be. Currently I can only reliably run make to generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure.

Eliot, How do you determine its an invalid configure file? I just ran 'make' in platforms/unix/config without error, although the diff lines is 40k.

Curiously the configure file committed Mar 13, 2015 was Generated by GNU Autoconf 2.59. which is 2003 vintage per... https://ftp.gnu.org/gnu/autoconf/?C=M;O=D or 2008 per... http://git.savannah.gnu.org/gitweb/?p=autoconf.git which still seems pretty old.

The configure I generated was... Generated by GNU Autoconf 2.69. which even though four years old seems to be the latest release per... http://git.savannah.gnu.org/gitweb/?p=autoconf.git

cheers -ben

...

...

...

...

...

>>> We hope to eliminate configure soon and use a makefile style similar to the Mac and Windows platforms. Do you have energy to contribute to this? >>> >>>> >>>> >>>> Thanks in advance. >>>> >>>> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for a better way to do it.

Hi Tim, that's because most of us let that job to bots nowadays... for example, gmail web interface just show me a minimal context, the rest is materialized as 3 dots : ... removing any content from the thread would cost me more clicks, scroll select, backspace... If you think that it's not good for the planet, and rather old mail reader unfriendly, just complain to google, because they made it good for us and biased our behavior. Beware, I fear you'll have to fight windmills...

2016-10-16 23:40 GMT+02:00 tim Rowledge tim@rowledge.org:

Folks, please - trim your damn posts. Do we really need an entire chapter of ‘Leo Tolstoy” by Warren Peese quoted just to include a “+1” buried in the middle? It pretty much removes any value to your post.

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CPM: Change Programmer's Mind

On 10/16/2016 6:37 PM, tim Rowledge wrote:

On 16-10-2016, at 3:20 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:

...

that's because most of us let that job to bots nowadays…

For goodness’ sake, think of the electrons! Don’t waste bits; remember there are children offline in less-affluent parts of the world.

Tim, doesn't that depend on the selected theme? Standard black fonts on a white background ought be saving electrons. But, well, that's due to more of a Dirac mindset rather than a potential cat. Just be positronic!

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I came, I saw, I deleted all your files.

Veni, Vidi, deletae omnes files

Hi Ben,

On Sun, Oct 16, 2016 at 12:35 PM, Ben Coman btc@openinworld.com wrote:

On Mon, Oct 17, 2016 at 2:33 AM, Tobias Pape Das.Linux@gmx.de wrote:

...

On 16.10.2016, at 20:27, Esteban Lorenzano estebanlm@gmail.com wrote:

...

...

On 16 Oct 2016, at 20:03, Ben Coman btc@openInWorld.com wrote:

On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

I would like to get more feedback regarding the summary I posted a

week ago. Reverse engineering configure to get configure.ac has meant a lot of work (see my progress attached) yet I still believe this step is crucial to tidy up our build system and add new platforms more easily, by adding more and *better* tests to configure.ac.

...

...

...

...

Please let me know if there's any interest on this or whether you

want to follow a different approach.

...

...

...

...

On Sat, Oct 8, 2016 at 12:27 AM, Gerardo Santana Gómez Garrido <

gerardo.santana@gmail.com> wrote:

...

...

...

...

...

To summarize it:

1. use simple, hand tailored, GNU Makefiles for building
2. generate and distribute a config.h once per platform
3. re-generate them only when a new platform is added or a current

platform has had significant changes

...

...

...

...

...

For #3 to happen we need a configure script to do it. New platforms

or changes to current ones will certainly mean adding tests to the configure script and so we also need configure.ac, for maintaining it.

...

...

...

...

...

Sadly, it seems that the configure script was being generated and

checked into the source tree without the corresponding configure.ac. FYI, I'm working on reverse engineering it to get the original configure.ac. After that it will be easy to move to where we want to be.

...

...

...

...

...

On Wed, Oct 5, 2016 at 8:38 PM, Gerardo Santana Gómez Garrido <

gerardo.santana@gmail.com> wrote:

...

...

...

...

...

> > Yes, makes sense. Thanks. I will work on simplify it, based on your

directives.

...

...

...

...

...

> > On Tue, Oct 4, 2016 at 2:16 PM, Eliot Miranda <

eliot.miranda@gmail.com> wrote:

...

...

...

...

...

>> >> Hi Gerardo, >> >> On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <

gerardo.santana@gmail.com> wrote:

...

...

...

...

...

>>> >>> Yes, energy and will. >>> >>> Actually I would like to keep autoconf. I found out some

duplicated code in the build.* directories that could probably be solved by using the autotools properly.

...

...

...

...

...

>>> >>> Are you strongly opposed to using autotools? May I try to make it

work?

...

...

...

...

...

>> >> >> No, I'm not. I'm opposed to running it on each build. The scheme

we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this):

...

...

...

...

...

>> >> 1. The correct realm for autoconf is in determining what

facilities the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h.

...

...

...

...

...

>> >> 2. the VM is to be configured from config.h (which informs us as

to what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries).

...

...

...

...

...

>> >> So the build scheme we're trying to move towards is >> >> a) either autoconf or CMake is used to generate a config.h file in

each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build

...

...

...

...

...

>> >> b) use conventional Gnu Make makefiles, avoiding all the mkmf

scripts in platforms/unix/conf, to build specific VMs

...

...

...

...

...

>> >> Does that make sense? For me this is very important. See >> >> http://lists.pharo.org/pipermail/pharo-dev_lists.

pharo.org/2016-February/119002.html

...

...

...

...

...

>> >> and this is from a Squeak Oversight Board discussion before we

moved to githug:

...

...

...

...

...

>> >> "It was decided to leave the build system as-is using GNU

Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))."

...

...

...

Is the CMake approach certain, or yet to be proven? Maybe CMake fits in better than autoconf with the third party libs used by Pharo ?

...

From my naive reading CMake seems a better cross platform choice than

autoconf, but it seems that CMake can't separate out generating just a config.h file from generating the build makefiles, a part that seems not wanted. Does anyone know any different? I've signed up to the CMake mail list to try to clarify this.

On the flip side, most of the stuff I read about autoconf is that it is very unix based and not suited for cross-platform with native MSWindows MSVC. Except an enabler might be CCCL, a gcc compatibility wrapper for the MSVC command-line.... https://github.com/swig/cccl#autotools-and-msvc https://folti.blogs.balabit.com/2009/08/compiling-

autoconfmake-projects-under-msvc-part-one/

...

...

...

What is the future of (IIUC) Pharo's dynamic generation of Cmake files?

in my talk with Eliot, config.h (named cogConfig.h) generation will be

moved to one or the other, the one that is easier. There was not a “use this” decision.

...

...

today, I’m more closer to the opinion of using autoconf instead cmake.

Main reason is that we already use autoconf for linux so why add yet-another-tool?

...

Sorry, but CMake has been used since 2006 for the Interpreter VM on

Linux replacing Autoconf there…

...

CMake is much less convoluted than Autoconf.

...

anyway, that’s what I have from my side. Not squeak board but pharo

board :)

...

...

Esteban

...

...

...

>> >> >> >> >>> >>> On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda <

eliot.miranda@gmail.com> wrote:

...

...

...

...

...

>>>> >>>> Hi Gerardo, >>>> >>>> welcome! >>>> >>>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido <

gerardo.santana@gmail.com> wrote:

...

...

...

...

...

>>>>> >>>>> Hi Eliot, >>>>> >>>>> what is the proper way to ask questions regarding building Clog? >>>>> >>>>> I just found that in opensmalltalk-vm/platforms/unix/config,

configure is not in sync with configure.ac

...

...

...

I guess this observation comes from generating configure from configure.ac and finding a difference with the committed configure.

But I see the history date on these files seems in sync https://github.com/OpenSmalltalk/opensmalltalk-

vm/commits/Cog/platforms/unix/config/configure.ac

...

...

...

https://github.com/OpenSmalltalk/opensmalltalk-

vm/commits/Cog/platforms/unix/config/configure

...

...

...

so maybe its down to different environments?

I see your version on the right here... https://www.diffchecker.com/jAQEeQOn (valid 1 month only) has this different... AC_DEFUN([AC_ICONV], [ AC_CHECK_FUNC(_dyld_present,[],[ AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) ]) if test $ac_cv_iconv = yes; then LIBS="$LIBS -liconv" fi] )])

which I find in... https://github.com/OpenSmalltalk/opensmalltalk-

vm/blob/Cog/platforms/unix/vm/acinclude.m4

...

...

...

which is included by... https://github.com/OpenSmalltalk/opensmalltalk-

vm/blob/Cog/platforms/unix/config/aclocal.m4

...

...

...

which seems referenced by... https://github.com/OpenSmalltalk/opensmalltalk-

vm/blob/Cog/platforms/unix/config/Makefile

...

...

...

but I don't really know how they all fit together.

btw Eliot, I see the following... https://github.com/OpenSmalltalk/opensmalltalk-

vm/blob/Cog/platforms/unix/doc/HowToBuildFromSource.txt

...

...

...

describes running configure, but I wonder how much of that from 2010 is still relevant today?

In fact I learnt something new in that doc, reading... "by running the config.status script ... is much faster than running configure all over again. (In fact, make should detect any changes to the plugin configuration and re-run config.status for you automatically.) Note: `configure' doesn't actually create any files. The last thing it does is run `config.status' to create the configured files in blddir from the corresponding file.ins in the unix/config directory.

...

...

>>>> >>>> >>>> It may or may not be. Currently I can only reliably run make to

generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure.

...

...

...

Eliot, How do you determine its an invalid configure file? I just ran 'make' in platforms/unix/config without error, although the diff lines is 40k.

Curiously the configure file committed Mar 13, 2015 was Generated by GNU Autoconf 2.59. which is 2003 vintage per... https://ftp.gnu.org/gnu/autoconf/?C=M;O=D or 2008 per... http://git.savannah.gnu.org/gitweb/?p=autoconf.git which still seems pretty old.

The configure I generated was... Generated by GNU Autoconf 2.69. which even though four years old seems to be the latest release per... http://git.savannah.gnu.org/gitweb/?p=autoconf.git

What system did you run that on? I've tried running the autoconf on CentOS 6.5 and it fails. Hence I've stuck with building on an ancient CentOS 5.4. I'm happy to update but I need to know what is a functional context.

cheers -ben

...

...

...

...

...

>>>> We hope to eliminate configure soon and use a makefile style

similar to the Mac and Windows platforms. Do you have energy to contribute to this?

...

...

...

...

...

>>>> >>>>> >>>>> >>>>> Thanks in advance. >>>>> >>>>> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm

looking for a better way to do it.

...

What's bad with CMake? It works quite well.

Phil

On Sun, Oct 16, 2016 at 8:27 PM, Esteban Lorenzano estebanlm@gmail.com wrote:

...

On 16 Oct 2016, at 20:03, Ben Coman btc@openInWorld.com wrote:

On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido gerardo.santana@gmail.com wrote:

...

I would like to get more feedback regarding the summary I posted a week

ago. Reverse engineering configure to get configure.ac has meant a lot of work (see my progress attached) yet I still believe this step is crucial to tidy up our build system and add new platforms more easily, by adding more and *better* tests to configure.ac.

...

...

Please let me know if there's any interest on this or whether you want

to follow a different approach.

...

...

On Sat, Oct 8, 2016 at 12:27 AM, Gerardo Santana Gómez Garrido <

gerardo.santana@gmail.com> wrote:

...

...

...

To summarize it:

1. use simple, hand tailored, GNU Makefiles for building
2. generate and distribute a config.h once per platform
3. re-generate them only when a new platform is added or a current

platform has had significant changes

...

...

...

For #3 to happen we need a configure script to do it. New platforms or

changes to current ones will certainly mean adding tests to the configure script and so we also need configure.ac, for maintaining it.

...

...

...

Sadly, it seems that the configure script was being generated and

checked into the source tree without the corresponding configure.ac. FYI, I'm working on reverse engineering it to get the original configure.ac. After that it will be easy to move to where we want to be.

...

...

...

On Wed, Oct 5, 2016 at 8:38 PM, Gerardo Santana Gómez Garrido <

gerardo.santana@gmail.com> wrote:

...

...

...

...

Yes, makes sense. Thanks. I will work on simplify it, based on your

directives.

...

...

...

...

On Tue, Oct 4, 2016 at 2:16 PM, Eliot Miranda <

eliot.miranda@gmail.com> wrote:

...

...

...

...

...

Hi Gerardo,

On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <

gerardo.santana@gmail.com> wrote:

...

...

...

...

...

> > Yes, energy and will. > > Actually I would like to keep autoconf. I found out some duplicated

code in the build.* directories that could probably be solved by using the autotools properly.

...

...

...

...

...

> > Are you strongly opposed to using autotools? May I try to make it

work?

...

...

...

...

...

No, I'm not. I'm opposed to running it on each build. The scheme

we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this):

...

...

...

...

...

1. The correct realm for autoconf is in determining what facilities

the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h.

...

...

...

...

...

2. the VM is to be configured from config.h (which informs us as to

what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries).

...

...

...

...

...

So the build scheme we're trying to move towards is

a) either autoconf or CMake is used to generate a config.h file in

each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build

...

...

...

...

...

b) use conventional Gnu Make makefiles, avoiding all the mkmf

scripts in platforms/unix/conf, to build specific VMs

...

...

...

...

...

Does that make sense? For me this is very important. See

http://lists.pharo.org/pipermail/pharo-dev_lists.

pharo.org/2016-February/119002.html

...

...

...

...

...

and this is from a Squeak Oversight Board discussion before we moved

to githug:

...

...

...

...

...

"It was decided to leave the build system as-is using GNU Makefiles

where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))."

...

Is the CMake approach certain, or yet to be proven? Maybe CMake fits in better than autoconf with the third party libs used by Pharo ?

...

From my naive reading CMake seems a better cross platform choice than

autoconf, but it seems that CMake can't separate out generating just a config.h file from generating the build makefiles, a part that seems not wanted. Does anyone know any different? I've signed up to the CMake mail list to try to clarify this.

On the flip side, most of the stuff I read about autoconf is that it is very unix based and not suited for cross-platform with native MSWindows MSVC. Except an enabler might be CCCL, a gcc compatibility wrapper for the MSVC command-line.... https://github.com/swig/cccl#autotools-and-msvc https://folti.blogs.balabit.com/2009/08/compiling-

autoconfmake-projects-under-msvc-part-one/

...

What is the future of (IIUC) Pharo's dynamic generation of Cmake files?

in my talk with Eliot, config.h (named cogConfig.h) generation will be moved to one or the other, the one that is easier. There was not a “use this” decision. today, I’m more closer to the opinion of using autoconf instead cmake. Main reason is that we already use autoconf for linux so why add yet-another-tool?

anyway, that’s what I have from my side. Not squeak board but pharo board :)

Esteban

...

...

...

...

...

> > On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda <

eliot.miranda@gmail.com> wrote:

...

...

...

...

...

>> >> Hi Gerardo, >> >> welcome! >> >> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido <

gerardo.santana@gmail.com> wrote:

...

...

...

...

...

>>> >>> Hi Eliot, >>> >>> what is the proper way to ask questions regarding building Clog? >>> >>> I just found that in opensmalltalk-vm/platforms/unix/config,

configure is not in sync with configure.ac

...

I guess this observation comes from generating configure from configure.ac and finding a difference with the committed configure.

But I see the history date on these files seems in sync https://github.com/OpenSmalltalk/opensmalltalk-

vm/commits/Cog/platforms/unix/config/configure.ac

...

https://github.com/OpenSmalltalk/opensmalltalk-

vm/commits/Cog/platforms/unix/config/configure

...

so maybe its down to different environments?

I see your version on the right here... https://www.diffchecker.com/jAQEeQOn (valid 1 month only) has this different... AC_DEFUN([AC_ICONV], [ AC_CHECK_FUNC(_dyld_present,[],[ AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) ]) if test $ac_cv_iconv = yes; then LIBS="$LIBS -liconv" fi] )])

which I find in... https://github.com/OpenSmalltalk/opensmalltalk-

vm/blob/Cog/platforms/unix/vm/acinclude.m4

...

which is included by... https://github.com/OpenSmalltalk/opensmalltalk-

vm/blob/Cog/platforms/unix/config/aclocal.m4

...

which seems referenced by... https://github.com/OpenSmalltalk/opensmalltalk-

vm/blob/Cog/platforms/unix/config/Makefile

...

but I don't really know how they all fit together.

btw Eliot, I see the following... https://github.com/OpenSmalltalk/opensmalltalk-

vm/blob/Cog/platforms/unix/doc/HowToBuildFromSource.txt

...

describes running configure, but I wonder how much of that from 2010 is still relevant today?

In fact I learnt something new in that doc, reading... "by running the config.status script ... is much faster than running configure all over again. (In fact, make should detect any changes to the plugin configuration and re-run config.status for you automatically.) Note: `configure' doesn't actually create any files. The last thing it does is run `config.status' to create the configured files in blddir from the corresponding file.ins in the unix/config directory.

...

...

...

...

>> >> >> It may or may not be. Currently I can only reliably run make to

generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure.

...

Eliot, How do you determine its an invalid configure file? I just ran 'make' in platforms/unix/config without error, although the diff lines is 40k.

...

...

...

...

>> We hope to eliminate configure soon and use a makefile style

similar to the Mac and Windows platforms. Do you have energy to contribute to this?

...

...

...

...

...

>> >>> >>> >>> Thanks in advance. >>> >>> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm

looking for a better way to do it.