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))."
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
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):
- 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.
- 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))."
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
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):
- 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.
- 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
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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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):
- 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.
- 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 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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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):
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.
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?
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: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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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):
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.
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.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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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):
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.
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.
>> 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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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 16.10.2016, at 20:41, Esteban Lorenzano estebanlm@gmail.com wrote:
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).
see here :) https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/oldTrunk/platforms/un...
Ian went long streak for making things quite easy and useful…
And CMake being less convoluted than Autoconf… well, I’m not so sure, I suffered a lot both of them :)
Esteban
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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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):
- 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.
- 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.
I think we should defer this discussion again until we all are comfortable with the Gihtub workflow for opensmalltalk-vm
:)
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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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 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.
We should at least wait until Pharo 6 is out before any move to replace autotools with CMake, so there is time for discussion.
On Mon, Oct 17, 2016 at 3:35 AM, phil@highoctane.be 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
Phil, Could you outline the steps. Are you doing something other than this... https://github.com/pharo-project/pharo-vm
regards, Ben
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 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.
Phil
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
Just an interesting article I wanted to hang somewhere I could find it again... http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake...
cheers -ben
On Mon, Oct 17, 2016 at 11:30 PM, Ben Coman btc@openinworld.com wrote:
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)
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).
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 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.
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).
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).
On 18 Oct 2016, at 07:49, 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.
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)
XCode for macOS you need to create a “fake” xcode project pointing to sources (but you do not need to “add” sources), it works… fine (I didn’t spend much time optimising it, anyway)
Eclipse CDT standalone debugger for linux/win this is fairly straightforward.
in both cases my approach is as follow:
- launch debugger/IDE - build debug/assert vm from command line - attach to running process
but that doesn’t mean I’m contrary to your approach, just that there are ways to use a decent debugger anyway :)
Esteban
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).
Does the simulator works in Pharo? Along with Display working? Clement seems to be working with a Squeak based one.
TIA Phil
On Wed, Oct 19, 2016 at 12:00 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
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).
-- _,,,^..^,,,_ best, Eliot
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 Wed, Oct 19, 2016 at 3:38 PM, 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.
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.
[1] opensmalltalk-vm$ find . -name mvm |wc -l 114
Most of those come from the repetition of the debug folders under the linux builds, which will improve when they become more like mac builds.
build.linux32ARMv6 18 build.linux32ARMv7 6 build.linux32x86 51 build.linux64x64 21
build.win32x86 6 build.win64x64 4
build.macos32x86 10 build.macos64x64 7
[2] opensmalltalk-vm$ find . -name makefile |wc -l 356
Strange I only get find . -iname makefile | wc -l
[3] opensmalltalk-vm$ find . -iname make* | wc -l 477 (- 88 makefiles)
What I get from... for d in * ; do echo $d find $d -iname makefile | wc -l done
build.linux32ARMv6 0 build.linux32ARMv7 0 build.linux32x86 1 build.linux64x64 0 build.macos32x86 20 build.macos64x64 17 build.win32x86 9 build.win64x64 6 platforms 48 processors 12
Now most of the mac makefiles are three lines long e.g. build.macos32x86/squeak.cog.spur/Makefile
And to drilling into platforms... Cross 3 iOS 29 Mac OS 0 Plan9 0 RiscOS 1 unix 6 win32 9
and processors... ARM 6 IA32 6
Now performing an actual build I get this maybe makefiles mybuild 53
so it seems the autogeneration of makefiles seems the big culprit, and I'd expect CMake may be similar here.
[4] opensmalltalk-vm$ ls -d1 build.{mac,win}*/*.*.*/ | wc -l 28 opensmalltalk-vm$ ls -d1 build.linux*/*.*.*/build* | wc -l 87
The linux build system is planned to become more like win & mac, so consider that 87 coming down to around 14 ??
(gotta run)
cheers -ben
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
On Wed, Oct 19, 2016 at 9:18 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 19.10.2016, at 15:00, Ben Coman btc@openinworld.com wrote:
Strange I only get find . -iname makefile | wc -l
Whoops. I meant to add the result was 113 on a fresh clone. (I had to shut my laptop down in a hurry to change locations.)
cheers -ben
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 Sun, Oct 16, 2016 at 8:33 PM, 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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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.
+ 1000
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
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 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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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.
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
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 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 -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I came, I saw, I deleted all your files.
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
On 10/16/2016 6:55 PM, Robert Withers wrote:
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!
Yes, that's
( β m c 2 + c ( ∑ n = 1 3 α n p n ) ) ψ ( x , t ) = i ℏ ∂ ψ ( x , t ) ∂ t {\displaystyle \left(\beta mc^{2}+c\left(\sum _{n{\mathop {=}}1}^{3}\alpha _{n}p_{n}\right)\right)\psi (x,t)=i\hbar {\frac {\partial \psi (x,t)}{\partial t}}} \left(\beta mc^{2}+c\left(\sum _{n{\mathop {=}}1}^{3}\alpha _{n}p_{n}\right)\right)\psi (x,t)=i\hbar {\frac {\partial \psi (x,t)}{\partial t}}
so you see, electrons are conserved when you hide them. 'His colleagues in Cambridge defined a unit of a "dirac", which was one word per hour.'. If you worry about the paucity of offline children, give them little carpets so they make their own electrons then, I am meaning 'teach them how to fish'. :_)
tim
tim Rowledge;tim@rowledge.org;http://www.rowledge.org/tim I came, I saw, I deleted all your files.
Veni, Vidi, deleri omnem lima
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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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
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.
On Tue, Oct 18, 2016 at 5:23 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Ben,
On Sun, Oct 16, 2016 at 12:35 PM, Ben Coman btc@openinworld.com wrote:
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.
I ran it on Debian 8 Jessie. However you can choose you favourite... https://distrowatch.com/search.php?pkg=autoconf&relation=similar&pkg...
Select a distro, then select "All tracked packages" and <Refresh>.
cheers -ben
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:
- use simple, hand tailored, GNU Makefiles for building
- generate and distribute a config.h once per platform
- 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):
- 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.
- 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
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
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.
vm-dev@lists.squeakfoundation.org