gmane.lisp.scheme.scheme48

Jonathan Rees | 24 Jun 22:50

Unuseable target in Makefile

[jar <at> ashby scheme48-1.8]$ make build/initial.image-64
make: *** No rule to make target `build/UnicodeData.txt', needed by  
`scheme/rts/syntax-info.scm'.  Stop.
[jar <at> ashby scheme48-1.8]$
[jar <at> ashby scheme48-1.8]$
[jar <at> ashby scheme48-1.8]$

What is the point of having a target in the distribution's Makefile,  
if it can't be made?

I would suggest making sure all targets can be made, in either of two  
ways:
1. remove unmakeable targets so that they're not a tease, and put them  
in a second distribution package, or
2. add sufficient rules to permit the target to be made.

In this case, if one can get the needed source files from the web,  
include a rule to do so (using, say, wget), or emit manual  
instructions telling people like me where to get the files and where  
to put them.

I assume the entire URL is http://www.unicode.org/Public/UNIDATA/UnicodeData.txt 
  and that the other four URLs are constructed similarly; maybe that  
could be put in the Makefile as documentation.

--------------------------------

OK, in the time it took me to write the above, I've become stuck in a  
different way:

(Continue reading)

headers

Michael Sperber | 25 Jun 08:13

Re: Unuseable target in Makefile


Jonathan Rees <jar <at> creativecommons.org> writes:

> What is the point of having a target in the distribution's Makefile,
> if it can't be made?

The files should be in the tarball; will fix.  Generally, if you've done
something that changes the initial image, I recommend working off the
stable source code from here, rather than the tarball.  Instructions are
here:

http://www.s48.org/development.html

> OK, in the time it took me to write the above, I've become stuck in a
> different way:
>
> [module-system]
> [analysis scheme/opt/analyze.scm]
> [ensures-loaded scheme/env/load-package.scm]
> Reifying
> ................................................................................................................
> Writing linker debug file build/reify-debug.tmp
> (least 0 size 2770 count 1456)
>
> Error: undefined variable
>        set-port-crlf?!
>        (package user)
> make: *** [build/initial.image-64] Error 1
> [jar <at> ashby scheme48-1.8]$

(Continue reading)

headers

Jonathan Rees | 25 Jun 18:17

Re: Unuseable target in Makefile

On Wed, Jun 25, 2008 at 2:13 AM, Michael Sperber <sperber <at> deinprogramm.de> wrote:

Generally, if you've done
something that changes the initial image, I recommend working off the
stable source code from here, rather than the tarball.

May I suggest you not sit on the fence here. If you support making initial image changes based on the distribution, and I think you must, then do so fully and with gusto. Anyone who does this kind of modification will understand the tradeoff between working with some distribution vs. working with the latest sources, so the recommendation should be unnecessary, and it raises uncertainty around the quality and completeness of the distribution that I don't think you mean to imply.

Thanks for the pointer to the info on the post-1.4 Unicode bump-in-the-road, which I had missed because I hadn't read the Makefile all the way through and because it wasn't anywhere near the target I was interested in (initial.image). I don't fully understand why I have to know anything about it or why you want to assume a Unicode-capable boot platform. I guess we have had to customize the static linker for various other hosting platforms (Lucid Common Lisp and Scheme->C being the ones I worked with most recently), so customizing differently for S48 1.4 and 1.5 is plausible, but the dependency seems unfortunate, and it is especially unfortunate that it fails in such an obscure way.

For now I am reverting to version 1.4, until the next time I need to open another >2G file.

And yes, I understand that overall the whole build and distribution process is in much better shape than when I last worked on it.

Jonathan

headers

Michael Sperber | 25 Jun 18:40

Re: Unuseable target in Makefile


"Jonathan Rees" <jar <at> creativecommons.org> writes:

> On Wed, Jun 25, 2008 at 2:13 AM, Michael Sperber <sperber <at> deinprogramm.de>
> wrote:
>
>>  Generally, if you've done
>> something that changes the initial image, I recommend working off the
>> stable source code from here, rather than the tarball.
>
>
> May I suggest you not sit on the fence here. If you support making initial
> image changes based on the distribution, and I think you must, then do so
> fully and with gusto.

Absolutely: It's a bug, and I'll fix it for the next release.

This was just a recommendation: If you're making changes, it's much
easier to keep track of progress in the baseline if you've checked it
out from revision control.

> Thanks for the pointer to the info on the post-1.4 Unicode bump-in-the-road,
> which I had missed because I hadn't read the Makefile all the way through
> and because it wasn't anywhere near the target I was interested in
> (initial.image).  I don't fully understand why I have to know anything about
> it or why you want to assume a Unicode-capable boot platform.

The image is a binary file, and R5RS provides no portable means for
writing a binary file.

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla