From: Daniel H. <dhe...@te...> - 2010-07-04 05:09:54
|
Hi all, A while ago, I submitted a patch that allowed the user to pass an install prefix to make.sh. It was rejected, and not without reason. Here's a refined attempt, based on sbcl 1.40. First I split out the general improvements to make.sh from (see 0001). Then I improved the prefix support (see 0002). Please consider these patches. Thanks, Daniel |
From: Daniel H. <dhe...@te...> - 2010-04-03 07:17:07
Attachments:
0001-build-improvements.patch
|
The attached patch should apply cleanly to any revision near 1.0.37.29. - give make.sh a real command-line parser - add help to make.sh - add an option to specify the default SBCL_HOME It was lightly tested; --prefix works for me, but I didn't fully excercise --xc-host or "make.sh HOST". Later, Daniel |
From: Nikodemus S. <nik...@ra...> - 2010-04-04 15:27:11
|
On 3 April 2010 10:16, Daniel Herring <dhe...@te...> wrote: > The attached patch should apply cleanly to any revision near 1.0.37.29. > > - give make.sh a real command-line parser > - add help to make.sh > - add an option to specify the default SBCL_HOME > > It was lightly tested; --prefix works for me, but I didn't fully excercise > --xc-host or "make.sh HOST". Thank you for the patch. However: " +# Parse command-line arguments +# loop based on ./configure from Autoconf 2.65 +ac_prev= " Can you clarify the license situation of autoconf ./configure scripts for me? I took a look at autoconf/COPYING.EXCEPTION, but I'm not sure I understand it. Sorry to be difficult about this! Otherwise I'm mostly happy with the patch -- it's definitely a step in the right direction, IMO. Cheers, -- Nikodemus |
From: Daniel H. <dhe...@te...> - 2010-04-05 04:33:02
|
On Sun, 4 Apr 2010, Nikodemus Siivola wrote: > On 3 April 2010 10:16, Daniel Herring <dhe...@te...> wrote: > >> The attached patch should apply cleanly to any revision near 1.0.37.29. >> >> - give make.sh a real command-line parser >> - add help to make.sh >> - add an option to specify the default SBCL_HOME >> >> It was lightly tested; --prefix works for me, but I didn't fully excercise >> --xc-host or "make.sh HOST". > > " > +# Parse command-line arguments > +# loop based on ./configure from Autoconf 2.65 > +ac_prev= > " > > Can you clarify the license situation of autoconf ./configure scripts > for me? I took a look at autoconf/COPYING.EXCEPTION, but I'm not sure > I understand it. >From the top of said script, "" #! /bin/sh # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.65 for ... ... # This configure script is free software; the Free Software Foundation # gives unlimited permission to copy, distribute and modify it. "" I've always taken that to mean its fair game for anything, especially stock parts like the parsing loop. - Daniel |
From: Daniel H. <dhe...@te...> - 2010-04-06 03:26:28
Attachments:
0001-build-improvements.patch
|
Gah! I had attached the wrong patch. This one fixes a minor typo and a major error in the GNUMakefile. - Daniel On Sat, 3 Apr 2010, Daniel Herring wrote: > The attached patch should apply cleanly to any revision near 1.0.37.29. > > - give make.sh a real command-line parser > - add help to make.sh > - add an option to specify the default SBCL_HOME > > It was lightly tested; --prefix works for me, but I didn't fully excercise > --xc-host or "make.sh HOST". > > > Later, > Daniel |
From: Nikodemus S. <nik...@ra...> - 2010-08-15 14:09:52
|
On 4 July 2010 08:09, Daniel Herring <dhe...@te...> wrote: > A while ago, I submitted a patch that allowed the user to pass an install > prefix to make.sh. It was rejected, and not without reason. > > Here's a refined attempt, based on sbcl 1.40. First I split out the general > improvements to make.sh from (see 0001). Then I improved the prefix support > (see 0002). > > Please consider these patches. Thank you. I've commited something based on these patches as 1.0.41.45. Note that the the XC host specification has been changed in an incompatible manner: OLD: make.sh "xc host command here" NEW: make.sh --xc-host="xc host command here" Cheers, -- Nikodemus |
From: Josh E. <jo...@el...> - 2010-08-15 16:58:39
|
On Sun, Aug 15, 2010 at 05:09:44PM +0300, Nikodemus Siivola wrote: > On 4 July 2010 08:09, Daniel Herring <dhe...@te...> wrote: > > > A while ago, I submitted a patch that allowed the user to pass an install > > prefix to make.sh. ??It was rejected, and not without reason. > > > > Here's a refined attempt, based on sbcl 1.40. ??First I split out the general > > improvements to make.sh from (see 0001). ??Then I improved the prefix support > > (see 0002). > > > > Please consider these patches. > > Thank you. I've commited something based on these patches as 1.0.41.45. > > Note that the the XC host specification has been changed in an > incompatible manner: > > OLD: make.sh "xc host command here" > > NEW: make.sh --xc-host="xc host command here" > > Cheers, > > -- Nikodemus You probably want to change the usage message to suggest "clisp -norc" instead of just "clisp". |
From: Christophe R. <cs...@ca...> - 2010-08-15 17:31:14
|
Josh Elsasser <jo...@el...> writes: > You probably want to change the usage message to suggest "clisp -norc" > instead of just "clisp". When I've used clisp in the past (a long time ago now) I've also needed "-on-error abort". It's also worth putting -ansi on there too, not that I think it matters at the moment. (I believe that newer versions of clisp signal full WARNINGs for fairly innocuous matters of lisp style, and so sbcl probably won't currently build under those. Older ones worked for me with "-ansi -on-error abort") Cheers, Christophe |
From: Nikodemus S. <nik...@ra...> - 2010-08-16 10:03:46
|
On 15 August 2010 20:31, Christophe Rhodes <cs...@ca...> wrote: > Josh Elsasser <jo...@el...> writes: > >> You probably want to change the usage message to suggest "clisp -norc" >> instead of just "clisp". > > When I've used clisp in the past (a long time ago now) I've also needed > "-on-error abort". It's also worth putting -ansi on there too, not that > I think it matters at the moment. The text was pretty much take verbatim from the old comment in make.sh. On reflection I actually inclined to take out other than CMUCL and SBCL examples, since those are the only hosts I've ever used regularly, and less likely to go stale soon -- anyone willing to keep other examples up to date is of course invited to do so... Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2010-08-17 12:48:27
|
Now that make.sh has command-line arguments, I'm tempted to add options for "intended for users" *features* so that customize-target-features.lisp is not needed anymore for casual builders. Any thoughts on this? Cheers, -- Nikodemus |
From: Gábor M. <me...@re...> - 2010-08-17 13:01:56
|
On Tue, Aug 17, 2010 at 2:48 PM, Nikodemus Siivola <nik...@ra...> wrote: > Now that make.sh has command-line arguments, I'm tempted to add > options for "intended for users" *features* so that > customize-target-features.lisp is not needed anymore for casual > builders. > > Any thoughts on this? Would those options stick around and affect subsequent builds a'la autoconf and c-t-f.lisp? |
From: Alastair B. <ala...@gm...> - 2010-08-17 13:05:56
|
On Tue, Aug 17, 2010 at 8:48 AM, Nikodemus Siivola <nik...@ra...> wrote: > Now that make.sh has command-line arguments, I'm tempted to add > options for "intended for users" *features* so that > customize-target-features.lisp is not needed anymore for casual > builders. > > Any thoughts on this? Please don't limit it to those features "intended for users", even if you only document it for such features. Being able to add (or remove), say, :unwind-to-frame-and-call-vop or similar backend-specific features at build time without hacking either c-t-f or make-config would be convenient when doing backend hacking or testing. -- Alastair Bridgewater |
From: Nikodemus S. <nik...@ra...> - 2010-08-17 13:07:01
|
2010/8/17 Gábor Melis <me...@re...>: > On Tue, Aug 17, 2010 at 2:48 PM, Nikodemus Siivola > <nik...@ra...> wrote: >> Now that make.sh has command-line arguments, I'm tempted to add >> options for "intended for users" *features* so that >> customize-target-features.lisp is not needed anymore for casual >> builders. >> >> Any thoughts on this? > > Would those options stick around and affect subsequent builds a'la > autoconf and c-t-f.lisp? I'm thinking no. ./make.sh --threads=yes --docstrings=no would build without docstrings and with threads, but plain ./make.sh after that would do whatever the default was. Of course we could have a separate ./configure step and save the options for future builds. Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2010-08-17 13:09:41
|
On 17 August 2010 16:05, Alastair Bridgewater <ala...@gm...> wrote: > Please don't limit it to those features "intended for users", even if > you only document it for such features. Being able to add (or > remove), say, :unwind-to-frame-and-call-vop or similar > backend-specific features at build time without hacking either c-t-f > or make-config would be convenient when doing backend hacking or > testing. Good point. Maybe "user-friendly" features get named options, but you could also add an arbitrary number of --enable=feature-name --disable=feature-name options? ...or maybe just the latter, for simplicity's sake? Cheers, -- Nikodemus |
From: Gábor M. <me...@re...> - 2010-08-17 13:24:39
|
2010/8/17 Nikodemus Siivola <nik...@ra...>: > 2010/8/17 Gábor Melis <me...@re...>: >> On Tue, Aug 17, 2010 at 2:48 PM, Nikodemus Siivola >> <nik...@ra...> wrote: >>> Now that make.sh has command-line arguments, I'm tempted to add >>> options for "intended for users" *features* so that >>> customize-target-features.lisp is not needed anymore for casual >>> builders. >>> >>> Any thoughts on this? >> >> Would those options stick around and affect subsequent builds a'la >> autoconf and c-t-f.lisp? > > I'm thinking no. > > ./make.sh --threads=yes --docstrings=no > > would build without docstrings and with threads, but plain ./make.sh > after that would do whatever the default was. > > Of course we could have a separate ./configure step and save the > options for future builds. As much as I'm a fan of autoconf (very little) there is some value in being superficially similar to it, if only for sake of familiarity. As to whether to persist options, if it's an exclusive choice then I vote for persisting. |
From: Nikodemus S. <nik...@ra...> - 2010-08-17 13:53:48
|
2010/8/17 Gábor Melis <me...@re...>: >> Of course we could have a separate ./configure step and save the >> options for future builds. > > As much as I'm a fan of autoconf (very little) there is some value in > being superficially similar to it, if only for sake of familiarity. As > to whether to persist options, if it's an exclusive choice then I vote > for persisting. Unless we separate out ./configure (or ./make-config.sh or whatever), persisting options seems confusing to me. A trivial non-confusing option for persisting without ./configure would be to add echo $0 $* >> make.log to make.sh, and have remake.sh along the lines of #!/bin/sh sh `tail -n1 make.log` ...not really sure if I'm serious or not. Cheers, -- Nikodemus |
From: Josh E. <jo...@el...> - 2010-08-17 15:22:36
|
On Sun, Aug 15, 2010 at 05:09:44PM +0300, Nikodemus Siivola wrote: > On 4 July 2010 08:09, Daniel Herring <dhe...@te...> wrote: > > > A while ago, I submitted a patch that allowed the user to pass an install > > prefix to make.sh. ??It was rejected, and not without reason. > > > > Here's a refined attempt, based on sbcl 1.40. ??First I split out the general > > improvements to make.sh from (see 0001). ??Then I improved the prefix support > > (see 0002). > > > > Please consider these patches. > > Thank you. I've commited something based on these patches as 1.0.41.45. > > Note that the the XC host specification has been changed in an > incompatible manner: > > OLD: make.sh "xc host command here" > > NEW: make.sh --xc-host="xc host command here" > > Cheers, > > -- Nikodemus The "function" keyword is a bash-ism, the posix defines simply functioname() diff --git make.sh make.sh index 8ab680d..599c8da 100755 --- make.sh +++ make.sh @@ -39,7 +39,7 @@ SBCL_XC_HOST="sbcl --disable-debugger --no-userinit --no-sysinit" export SBCL_XC_HOST # Parse command-line options. -function bad_option() { +bad_option() { echo $1 echo "Enter \"$0 --help\" for list of valid options." exit 1 |
From: Nikodemus S. <nik...@ra...> - 2010-08-17 16:02:53
|
On 17 August 2010 18:22, Josh Elsasser <jo...@el...> wrote: > The "function" keyword is a bash-ism, the posix defines simply > functioname() Oops, thanks! Cheers, -- Nikodemus |
From: Gabriel D. R. <gd...@in...> - 2010-08-17 16:20:39
|
2010/8/17 Nikodemus Siivola <nik...@ra...>: > 2010/8/17 Gábor Melis <me...@re...>: > >>> Of course we could have a separate ./configure step and save the >>> options for future builds. >> >> As much as I'm a fan of autoconf (very little) there is some value in >> being superficially similar to it, if only for sake of familiarity. As >> to whether to persist options, if it's an exclusive choice then I vote >> for persisting. > > Unless we separate out ./configure (or ./make-config.sh or whatever), > persisting options seems confusing to me. > > A trivial non-confusing option for persisting without ./configure > would be to add > > echo $0 $* >> make.log > > to make.sh, and have remake.sh along the lines of > > #!/bin/sh > sh `tail -n1 make.log` > > ...not really sure if I'm serious or not. > I agree that simplicity should prevail. Unless there is a serious need for autoconf like configure, I would suggest to stick with simple usable options for make.sh. If it starts doing autoconf stuff, then there should be a separate configure script. |
From: Nikodemus S. <nik...@ra...> - 2010-08-17 16:43:56
|
On 17 August 2010 19:20, Gabriel Dos Reis <gd...@in...> wrote: > I agree that simplicity should prevail. > Unless there is a serious need for autoconf like > configure, I would suggest to stick with simple usable > options for make.sh. > If it starts doing autoconf stuff, then there should be > a separate configure script. To avoid confusion: I am strongly opposed to autoconf. It's not on the table as far as I am concerned. What I'm cool with is to a separate ./configure script, allowing options to persist across make.sh invocations. I don't feel strongly about it either way. Cheers, -- Nikodemus |
From: <dhe...@te...> - 2010-08-17 18:17:11
|
Nikodemus wrote: > On 17 August 2010 16:05, Alastair Bridgewater > <ala...@gm...> wrote: > >> Please don't limit it to those features "intended for users", even if >> you only document it for such features. Â Being able to add (or >> remove), say, :unwind-to-frame-and-call-vop or similar >> backend-specific features at build time without hacking either c-t-f >> or make-config would be convenient when doing backend hacking or >> testing. > > Good point. > > Maybe "user-friendly" features get named options, but you could also > add an arbitrary number of --enable=feature-name > --disable=feature-name options? > > ...or maybe just the latter, for simplicity's sake? For an autoconf feel, I would recommend the standard --enable-feature and --disable-feature flags (or --with-tool and --without-tool). But then there's a big mapping that needs to be maintained. For a lispy feel, maybe we could put the keywords directly on the command line? All keywords could be automatically collected and inserted into the local config list. AFAICT, most keywords are command-line compatible. e.g. ./make.sh :unwind-to-frame-and-call-vop - Daniel |
From: Peter K. <ps...@cs...> - 2010-08-18 02:50:45
|
Hello, On Tue, Aug 17, 2010 at 01:49:26PM -0400, dhe...@te... wrote: > For an autoconf feel, I would recommend the standard --enable-feature and > --disable-feature flags (or --with-tool and --without-tool). But then > there's a big mapping that needs to be maintained. > > For a lispy feel, maybe we could put the keywords directly on the command > line? All keywords could be automatically collected and inserted into the > local config list. AFAICT, most keywords are command-line compatible. > > e.g. > ./make.sh :unwind-to-frame-and-call-vop I'm a simple user of SBCL who follows this list, but I found a few things wrong and would like to mention them: It turns out that the recent make.sh changes have broken the ability to build sbcl via clbuild (as of Aug 17 21:15 2010). The problem is that the clbuild shell script calls make.sh like this: sh make.sh "$3" and $3 happens to be undefined, causing it to be: sh make.sh "" which causes a bad option error from make.sh since it doesn't know what to do with a present, but empty, command line argument. As a separate problem, I also ran into this: Linux merlin > sh make.sh //Starting build: Tue Aug 17 21:29:47 CDT 2010 //Options: --prefix='/usr/local' --xc-host='sbcl --disable-debugger --no-userinit --no-sysinit' make.sh: line 142: output/prefix.def: No such file or directory Thank you. -pete |
From: Nikodemus S. <nik...@ra...> - 2010-08-18 14:57:41
|
On 18 August 2010 05:34, Peter Keller <ps...@cs...> wrote: > I'm a simple user of SBCL who follows this list, but I found a few things > wrong and would like to mention them: > > It turns out that the recent make.sh changes have broken the ability to build > sbcl via clbuild (as of Aug 17 21:15 2010). > > The problem is that the clbuild shell script calls make.sh like this: > > sh make.sh "$3" > > and $3 happens to be undefined, causing it to be: > > sh make.sh "" > > which causes a bad option error from make.sh since it doesn't know what to do > with a present, but empty, command line argument. I committed a few changes which should fix this for clbuild for now, most importantly temporary support for legacy-style xc-host specification and creating output/ early enough if it doesn't already exist. Please let me know if you still experience troubles with SBCL 1.0.41.53. That said, clbuild should be changed to use --xc-host sooner or later. Cheers, -- Nikodemus |
From: Peter K. <ps...@cs...> - 2010-08-18 18:55:00
|
On Wed, Aug 18, 2010 at 05:57:35PM +0300, Nikodemus Siivola wrote: > I committed a few changes which should fix this for clbuild for now, > most importantly temporary support for legacy-style xc-host > specification and creating output/ early enough if it doesn't already > exist. > > Please let me know if you still experience troubles with SBCL 1.0.41.53. No more troubles! Thank you. -pete |
From: Andreas F. <as...@bo...> - 2010-08-18 19:10:49
|
On Wed, Aug 18, 2010 at 16:57, Nikodemus Siivola <nik...@ra...> wrote: > I committed a few changes which should fix this for clbuild for now, > most importantly temporary support for legacy-style xc-host > specification and creating output/ early enough if it doesn't already > exist. Let me chime in here. First off, I'm very happy about the change to ./make.sh syntax. It will make building a lot easier, easier to understand, and more reliable. But I would like to make the case for providing a stable (throughout the ages) interface for building sbcl: Please leave the legacy make.sh command line syntax in place. AFAICT, it doesn't conflict with the new way of doing things, but helps everyone who wants to build every version of sbcl ever released. With each incompatible change to the user-facing side of the build interface, automated tools will break, and people have to come up with work-arounds. Now, this is me just speaking for my own lazy self, but I would like to not have to put version conditionals into boinkmarks for this... I had to do that for clisp, and it was really hard to maintain. Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs |