Hi Gerardo,
On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <[hidden email]> wrote:
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. 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 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))."
_,,,^..^,,,_ best, Eliot |
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 <[hidden email]> wrote:
Gerardo Santana
|
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 <[hidden email]> wrote:
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 <[hidden email]> wrote:
Gerardo Santana
acinclude.m4 (12K) Download Attachment acplugins.m4 (504 bytes) Download Attachment configure.ac (20K) Download Attachment |
On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>> >>>> Hi Gerardo, >>>> >>>> On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <[hidden email]> 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? >>>> >>>> >>>> >>>> >>>>> >>>>> On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda <[hidden email]> wrote: >>>>>> >>>>>> Hi Gerardo, >>>>>> >>>>>> welcome! >>>>>> >>>>>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido <[hidden email]> wrote: >>>>>>> >>>>>>> Hi Eliot, >>>>>>> >>>>>>> what is the proper way to ask questions regarding building Clog? >>>>>>> >>>>>>> I just found that in opensmalltalk-vm/platforms/unix/config, configure is not in sync with configure.ac I guess this observation comes from generating configure from configure.ac and finding a difference with the committed configure. But I see the history date on these files seems in sync https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix/config/configure.ac https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix/config/configure so maybe its down to different environments? I see your version on the right here... https://www.diffchecker.com/jAQEeQOn (valid 1 month only) has this different... AC_DEFUN([AC_ICONV], [ AC_CHECK_FUNC(_dyld_present,[],[ AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) ]) if test $ac_cv_iconv = yes; then LIBS="$LIBS -liconv" fi] )]) which I find in... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm/acinclude.m4 which is included by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/aclocal.m4 which seems referenced by... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/Makefile but I don't really know how they all fit together. btw Eliot, I see the following... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/doc/HowToBuildFromSource.txt describes running configure, but I wonder how much of that from 2010 is still relevant today? In fact I learnt something new in that doc, reading... "by running the config.status script ... is much faster than running configure all over again. (In fact, make should detect any changes to the plugin configuration and re-run config.status for you automatically.) Note: `configure' doesn't actually create any files. The last thing it does is run `config.status' to create the configured files in blddir from the corresponding file.ins in the unix/config directory. >>>>>> >>>>>> >>>>>> It may or may not be. Currently I can only reliably run make to generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure. Eliot, How do you determine its an invalid configure file? I just ran 'make' in platforms/unix/config without error, although the diff lines is 40k. >>>>>> We hope to eliminate configure soon and use a makefile style similar to the Mac and Windows platforms. Do you have energy to contribute to this? >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks in advance. >>>>>>> >>>>>>> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for a better way to do it. |
> On 16 Oct 2016, at 20:03, Ben Coman <[hidden email]> wrote: > > > On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido > <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>>> >>>>> Hi Gerardo, >>>>> >>>>> On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <[hidden email]> wrote: >>>>>> >>>>>> Yes, energy and will. >>>>>> >>>>>> Actually I would like to keep autoconf. I found out some duplicated code in the build.* directories that could probably be solved by using the autotools properly. >>>>>> >>>>>> Are you strongly opposed to using autotools? May I try to make it work? >>>>> >>>>> >>>>> No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this): >>>>> >>>>> 1. The correct realm for autoconf is in determining what facilities the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h. >>>>> >>>>> 2. the VM is to be configured from config.h (which informs us as to what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries). >>>>> >>>>> So the build scheme we're trying to move towards is >>>>> >>>>> a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build >>>>> >>>>> b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs >>>>> >>>>> Does that make sense? For me this is very important. See >>>>> >>>>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/119002.html >>>>> >>>>> and this is from a Squeak Oversight Board discussion before we moved to githug: >>>>> >>>>> "It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))." > > Is the CMake approach certain, or yet to be proven? Maybe CMake fits > in better than autoconf with the third party libs used by Pharo ? > >> From my naive reading CMake seems a better cross platform choice than > autoconf, but it seems that CMake can't separate out generating just a > config.h file from generating the build makefiles, a part that seems > not wanted. Does anyone know any different? I've signed up to the > CMake mail list to try to clarify this. > > On the flip side, most of the stuff I read about autoconf is that it > is very unix based and not suited for cross-platform with native > MSWindows MSVC. Except an enabler might be CCCL, a gcc compatibility > wrapper for the MSVC command-line.... > https://github.com/swig/cccl#autotools-and-msvc > https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-under-msvc-part-one/ > > > What is the future of (IIUC) Pharo's dynamic generation of Cmake files? in my talk with Eliot, config.h (named cogConfig.h) generation will be moved to one or the other, the one that is easier. There was not a “use this” decision. today, I’m more closer to the opinion of using autoconf instead cmake. Main reason is that we already use autoconf for linux so why add yet-another-tool? anyway, that’s what I have from my side. Not squeak board but pharo board :) Esteban > > > > >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda <[hidden email]> wrote: >>>>>>> >>>>>>> Hi Gerardo, >>>>>>> >>>>>>> welcome! >>>>>>> >>>>>>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido <[hidden email]> wrote: >>>>>>>> >>>>>>>> Hi Eliot, >>>>>>>> >>>>>>>> what is the proper way to ask questions regarding building Clog? >>>>>>>> >>>>>>>> I just found that in opensmalltalk-vm/platforms/unix/config, configure is not in sync with configure.ac > > I guess this observation comes from generating configure from > configure.ac and finding a difference with the committed configure. > > But I see the history date on these files seems in sync > https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix/config/configure.ac > https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix/config/configure > > so maybe its down to different environments? > > > I see your version on the right here... > https://www.diffchecker.com/jAQEeQOn (valid 1 month only) > has this different... > AC_DEFUN([AC_ICONV], [ > AC_CHECK_FUNC(_dyld_present,[],[ > AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ > AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) > ]) > if test $ac_cv_iconv = yes; then > LIBS="$LIBS -liconv" > fi] > )]) > > which I find in... > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm/acinclude.m4 > which is included by... > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/aclocal.m4 > which seems referenced by... > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/Makefile > but I don't really know how they all fit together. > > > btw Eliot, I see the following... > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/doc/HowToBuildFromSource.txt > describes running configure, but I wonder how much of that from 2010 > is still relevant today? > > In fact I learnt something new in that doc, reading... "by running the > config.status script ... is much faster than running configure all > over again. (In fact, make should detect any changes to the plugin > configuration and re-run config.status for you automatically.) Note: > `configure' doesn't actually create any files. The last thing it does > is run `config.status' to create the configured files in blddir from > the corresponding file.ins in the unix/config directory. > > >>>>>>> >>>>>>> >>>>>>> It may or may not be. Currently I can only reliably run make to generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure. > > Eliot, How do you determine its an invalid configure file? > I just ran 'make' in platforms/unix/config without error, although > the diff lines is 40k. > > >>>>>>> We hope to eliminate configure soon and use a makefile style similar to the Mac and Windows platforms. Do you have energy to contribute to this? >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks in advance. >>>>>>>> >>>>>>>> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for a better way to do it. |
On 16.10.2016, at 20:27, Esteban Lorenzano <[hidden email]> wrote: > > >> On 16 Oct 2016, at 20:03, Ben Coman <[hidden email]> wrote: >> >> >> On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido >> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>>>> >>>>>> Hi Gerardo, >>>>>> >>>>>> On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <[hidden email]> 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 <[hidden email]> wrote: >>>>>>>> >>>>>>>> Hi Gerardo, >>>>>>>> >>>>>>>> welcome! >>>>>>>> >>>>>>>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido <[hidden email]> 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. |
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
|
On 16.10.2016, at 20:41, Esteban Lorenzano <[hidden email]> 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/unix 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 |
In reply to this post by EstebanLM
What's bad with CMake? It works quite well. Phil On Sun, Oct 16, 2016 at 8:27 PM, Esteban Lorenzano <[hidden email]> wrote:
|
In reply to this post by Tobias Pape
On Sun, Oct 16, 2016 at 8:33 PM, Tobias Pape <[hidden email]> wrote:
+ 1000
|
In reply to this post by Tobias Pape
On Mon, Oct 17, 2016 at 2:33 AM, Tobias Pape <[hidden email]> wrote: > > > On 16.10.2016, at 20:27, Esteban Lorenzano <[hidden email]> wrote: > >> >> >>> On 16 Oct 2016, at 20:03, Ben Coman <[hidden email]> wrote: >>> >>> >>> On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido >>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>>>>> >>>>>>> Hi Gerardo, >>>>>>> >>>>>>> On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <[hidden email]> 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 <[hidden email]> wrote: >>>>>>>>> >>>>>>>>> Hi Gerardo, >>>>>>>>> >>>>>>>>> welcome! >>>>>>>>> >>>>>>>>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido <[hidden email]> wrote: >>>>>>>>>> >>>>>>>>>> Hi Eliot, >>>>>>>>>> >>>>>>>>>> what is the proper way to ask questions regarding building Clog? >>>>>>>>>> >>>>>>>>>> I just found that in opensmalltalk-vm/platforms/unix/config, configure is not in sync with configure.ac >>> >>> I guess this observation comes from generating configure from >>> configure.ac and finding a difference with the committed configure. >>> >>> But I see the history date on these files seems in sync >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix/config/configure.ac >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix/config/configure >>> >>> so maybe its down to different environments? >>> >>> >>> I see your version on the right here... >>> https://www.diffchecker.com/jAQEeQOn (valid 1 month only) >>> has this different... >>> AC_DEFUN([AC_ICONV], [ >>> AC_CHECK_FUNC(_dyld_present,[],[ >>> AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ >>> AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) >>> ]) >>> if test $ac_cv_iconv = yes; then >>> LIBS="$LIBS -liconv" >>> fi] >>> )]) >>> >>> which I find in... >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm/acinclude.m4 >>> which is included by... >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/aclocal.m4 >>> which seems referenced by... >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/Makefile >>> but I don't really know how they all fit together. >>> >>> >>> btw Eliot, I see the following... >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/doc/HowToBuildFromSource.txt >>> describes running configure, but I wonder how much of that from 2010 >>> is still relevant today? >>> >>> In fact I learnt something new in that doc, reading... "by running the >>> config.status script ... is much faster than running configure all >>> over again. (In fact, make should detect any changes to the plugin >>> configuration and re-run config.status for you automatically.) Note: >>> `configure' doesn't actually create any files. The last thing it does >>> is run `config.status' to create the configured files in blddir from >>> the corresponding file.ins in the unix/config directory. >>> >>> >>>>>>>>> >>>>>>>>> >>>>>>>>> It may or may not be. Currently I can only reliably run make to generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure. >>> >>> Eliot, How do you determine its an invalid configure file? >>> I just ran 'make' in platforms/unix/config without error, although >>> the diff lines is 40k. Curiously the configure file committed Mar 13, 2015 was Generated by GNU Autoconf 2.59. which is 2003 vintage per... https://ftp.gnu.org/gnu/autoconf/?C=M;O=D or 2008 per... http://git.savannah.gnu.org/gitweb/?p=autoconf.git which still seems pretty old. The configure I generated was... Generated by GNU Autoconf 2.69. which even though four years old seems to be the latest release per... http://git.savannah.gnu.org/gitweb/?p=autoconf.git 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. > |
In reply to this post by EstebanLM
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 <[hidden email]> wrote:
|
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, [hidden email] 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 <[hidden email]> wrote: > > >> On 16 Oct 2016, at 20:33, Tobias Pape <[hidden email]> wrote: >> >> >> >> On 16.10.2016, at 20:27, Esteban Lorenzano <[hidden email]> wrote: >> >>> >>> >>>> On 16 Oct 2016, at 20:03, Ben Coman <[hidden email]> wrote: >>>> >>>> >>>> On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido >>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>>>>>> >>>>>>>> Hi Gerardo, >>>>>>>> >>>>>>>> On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <[hidden email]> wrote: >>>>>>>>> >>>>>>>>> Yes, energy and will. >>>>>>>>> >>>>>>>>> Actually I would like to keep autoconf. I found out some duplicated code in the build.* directories that could probably be solved by using the autotools properly. >>>>>>>>> >>>>>>>>> Are you strongly opposed to using autotools? May I try to make it work? >>>>>>>> >>>>>>>> >>>>>>>> No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this): >>>>>>>> >>>>>>>> 1. The correct realm for autoconf is in determining what facilities the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h. >>>>>>>> >>>>>>>> 2. the VM is to be configured from config.h (which informs us as to what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries). >>>>>>>> >>>>>>>> So the build scheme we're trying to move towards is >>>>>>>> >>>>>>>> a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build >>>>>>>> >>>>>>>> b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs >>>>>>>> >>>>>>>> Does that make sense? For me this is very important. See >>>>>>>> >>>>>>>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/119002.html >>>>>>>> >>>>>>>> and this is from a Squeak Oversight Board discussion before we moved to githug: >>>>>>>> >>>>>>>> "It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))." >>>> >>>> Is the CMake approach certain, or yet to be proven? Maybe CMake fits >>>> in better than autoconf with the third party libs used by Pharo ? >>>> >>>>> From my naive reading CMake seems a better cross platform choice than >>>> autoconf, but it seems that CMake can't separate out generating just a >>>> config.h file from generating the build makefiles, a part that seems >>>> not wanted. Does anyone know any different? I've signed up to the >>>> CMake mail list to try to clarify this. >>>> >>>> On the flip side, most of the stuff I read about autoconf is that it >>>> is very unix based and not suited for cross-platform with native >>>> MSWindows MSVC. Except an enabler might be CCCL, a gcc compatibility >>>> wrapper for the MSVC command-line.... >>>> https://github.com/swig/cccl#autotools-and-msvc >>>> https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-under-msvc-part-one/ >>>> >>>> >>>> What is the future of (IIUC) Pharo's dynamic generation of Cmake files? >>> >>> in my talk with Eliot, config.h (named cogConfig.h) generation will be moved to one or the other, the one that is easier. There was not a “use this” decision. >>> today, I’m more closer to the opinion of using autoconf instead cmake. Main reason is that we already use autoconf for linux so why add yet-another-tool? >> >> Sorry, but CMake has been used since 2006 for the Interpreter VM on Linux replacing Autoconf there… >> CMake is much less convoluted than Autoconf. > > Well, the VM we use uses autoconf for building linux, I didn’t see any CMake. > In Pharo branch, we use CMake, so *in theory* I should prefer CMake over Autoconf. Now… I'm also a fan of keeping things as simple as possible, that’s why I would think carefully before introducing a new tool… (I do not know interpreter side). > > And CMake being less convoluted than Autoconf… well, I’m not so sure, I suffered a lot both of them :) > > Esteban > >> >>> >>> anyway, that’s what I have from my side. Not squeak board but pharo board :) >>> >>> Esteban >>> >>>> >>>> >>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda <[hidden email]> wrote: >>>>>>>>>> >>>>>>>>>> Hi Gerardo, >>>>>>>>>> >>>>>>>>>> welcome! >>>>>>>>>> >>>>>>>>>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido <[hidden email]> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Eliot, >>>>>>>>>>> >>>>>>>>>>> what is the proper way to ask questions regarding building Clog? >>>>>>>>>>> >>>>>>>>>>> I just found that in opensmalltalk-vm/platforms/unix/config, configure is not in sync with configure.ac >>>> >>>> I guess this observation comes from generating configure from >>>> configure.ac and finding a difference with the committed configure. >>>> >>>> But I see the history date on these files seems in sync >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix/config/configure.ac >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/unix/config/configure >>>> >>>> so maybe its down to different environments? >>>> >>>> >>>> I see your version on the right here... >>>> https://www.diffchecker.com/jAQEeQOn (valid 1 month only) >>>> has this different... >>>> AC_DEFUN([AC_ICONV], [ >>>> AC_CHECK_FUNC(_dyld_present,[],[ >>>> AC_CHECK_LIB(iconv, iconv_open, ac_cv_iconv=yes, [ >>>> AC_CHECK_LIB(iconv, libiconv_open, ac_cv_iconv=yes, ac_cv_iconv=no) >>>> ]) >>>> if test $ac_cv_iconv = yes; then >>>> LIBS="$LIBS -liconv" >>>> fi] >>>> )]) >>>> >>>> which I find in... >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm/acinclude.m4 >>>> which is included by... >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/aclocal.m4 >>>> which seems referenced by... >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/Makefile >>>> but I don't really know how they all fit together. >>>> >>>> >>>> btw Eliot, I see the following... >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/doc/HowToBuildFromSource.txt >>>> describes running configure, but I wonder how much of that from 2010 >>>> is still relevant today? >>>> >>>> In fact I learnt something new in that doc, reading... "by running the >>>> config.status script ... is much faster than running configure all >>>> over again. (In fact, make should detect any changes to the plugin >>>> configuration and re-run config.status for you automatically.) Note: >>>> `configure' doesn't actually create any files. The last thing it does >>>> is run `config.status' to create the configured files in blddir from >>>> the corresponding file.ins in the unix/config directory. >>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It may or may not be. Currently I can only reliably run make to generate a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an invalid configure. >>>> >>>> Eliot, How do you determine its an invalid configure file? >>>> I just ran 'make' in platforms/unix/config without error, although >>>> the diff lines is 40k. >>>> >>>> >>>>>>>>>> We hope to eliminate configure soon and use a makefile style similar to the Mac and Windows platforms. Do you have energy to contribute to this? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks in advance. >>>>>>>>>>> >>>>>>>>>>> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking for a better way to do it. > > > |
> On 16 Oct 2016, at 22:30, Tobias Pape <[hidden email]> 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, [hidden email] 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 <[hidden email]> wrote: >> >> >>> On 16 Oct 2016, at 20:33, Tobias Pape <[hidden email]> wrote: >>> >>> >>> >>> On 16.10.2016, at 20:27, Esteban Lorenzano <[hidden email]> wrote: >>> >>>> >>>> >>>>> On 16 Oct 2016, at 20:03, Ben Coman <[hidden email]> wrote: >>>>> >>>>> >>>>> On Sun, Oct 16, 2016 at 10:47 AM, Gerardo Santana Gómez Garrido >>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>>>>>>> >>>>>>>>> Hi Gerardo, >>>>>>>>> >>>>>>>>> On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido <[hidden email]> wrote: >>>>>>>>>> >>>>>>>>>> Yes, energy and will. >>>>>>>>>> >>>>>>>>>> Actually I would like to keep autoconf. I found out some duplicated code in the build.* directories that could probably be solved by using the autotools properly. >>>>>>>>>> >>>>>>>>>> Are you strongly opposed to using autotools? May I try to make it work? >>>>>>>>> >>>>>>>>> >>>>>>>>> No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this): >>>>>>>>> >>>>>>>>> 1. The correct realm for autoconf is in determining what facilities the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h. >>>>>>>>> >>>>>>>>> 2. the VM is to be configured from config.h (which informs us as to what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries). >>>>>>>>> >>>>>>>>> So the build scheme we're trying to move towards is >>>>>>>>> >>>>>>>>> a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build >>>>>>>>> >>>>>>>>> b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs >>>>>>>>> >>>>>>>>> Does that make sense? For me this is very important. See >>>>>>>>> >>>>>>>>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/119002.html >>>>>>>>> >>>>>>>>> and this is from a Squeak Oversight Board discussion before we moved to githug: >>>>>>>>> >>>>>>>>> "It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))." >>>>> >>>>> Is the CMake approach certain, or yet to be proven? Maybe CMake fits >>>>> in better than autoconf with the third party libs used by Pharo ? >>>>> >>>>>> From my naive reading CMake seems a better cross platform choice than >>>>> autoconf, but it seems that CMake can't separate out generating just a >>>>> config.h file from generating the build makefiles, a part that seems >>>>> not wanted. Does anyone know any different? I've signed up to the >>>>> CMake mail list to try to clarify this. >>>>> >>>>> On the flip side, most of the stuff I read about autoconf is that it >>>>> is very unix based and not suited for cross-platform with native >>>>> MSWindows MSVC. Except an enabler might be CCCL, a gcc compatibility >>>>> wrapper for the MSVC command-line.... >>>>> https://github.com/swig/cccl#autotools-and-msvc >>>>> https://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-projects-under-msvc-part-one/ >>>>> >>>>> >>>>> What is the future of (IIUC) Pharo's dynamic generation of Cmake files? >>>> >>>> in my talk with Eliot, config.h (named cogConfig.h) generation will be moved to one or the other, the one that is easier. There was not a “use this” decision. >>>> today, I’m more closer to the opinion of using autoconf instead cmake. Main reason is that we already use autoconf for linux so why add yet-another-tool? >>> >>> Sorry, but CMake has been used since 2006 for the Interpreter VM on Linux replacing Autoconf there… >>> CMake is much less convoluted than Autoconf. >> >> Well, the VM we use uses autoconf for building linux, I didn’t see any CMake. >> In Pharo branch, we use CMake, so *in theory* I should prefer CMake over Autoconf. Now… I'm also a fan of keeping things as simple as possible, that’s why I would think carefully before introducing a new tool… (I do not know interpreter side). >> >> And CMake being less convoluted than Autoconf… well, I’m not so sure, I suffered a lot both of them :) >> >> Esteban >> >>> >>>> >>>> anyway, that’s what I have from my side. Not squeak board but pharo board :) >>>> >>>> Esteban >>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda <[hidden email]> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Gerardo, >>>>>>>>>>> >>>>>>>>>>> welcome! >>>>>>>>>>> >>>>>>>>>>> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido <[hidden email]> 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. >> >> >> > |
In reply to this post by Ben Coman
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; [hidden email]; 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...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 <[hidden email]>:
|
> On 16-10-2016, at 3:20 PM, Nicolas Cellier <[hidden email]> 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; [hidden email]; 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 [hidden email] 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! Veni, Vidi, deletae omnes filestim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim I came, I saw, I deleted all your files. |
On 10/16/2016 6:55 PM, Robert Withers
wrote:
On 10/16/2016 6:37 PM, tim Rowledge wrote: Yes, that's
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'. :_) Veni, Vidi, deleri omnem limatim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim I came, I saw, I deleted all your files. |
Free forum by Nabble | Edit this page |