headers
Walter C. Pelissero | 2 Dec 2003 19:26
Picon

Re: new ops

[ Just realized I've answered to Daniel only, forgetting to
  copy to the mailing list.  So here is the message again complete
  of its typos. ]

Daniel Barlow writes:
 > What I suggest you do is package them separately.

Even though the addendum introduces a bit of ASDF's namespace
pollution, I'm not quite convinced that those three -ops would deserve
a package on its own, expecially when so tightly coupled with ASDF
itself: component-system and input-files are not exported.

 > (ii) as far as I can see you're only using the clocc stuff to set the
 > current directory

Right, the directory-stuff wasn't strictly necessary.  That has been
amended, and the few lines of CLOCC's code removed.

For those who care, the new version is at:

  http://www.pelissero.de/software/asdfa.lisp

--

-- 
walter pelissero
http://www.pelissero.de

-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Barlow | 18 Dec 2003 06:18

Re: asdf-install for cmucl?

Raymond Toy <toy <at> rtp.ericsson.se> writes:

> Note that this would be a contrib, not an "official" part of CMUCL.
> Ideally, this would be maintained elsewhere, but the cclan version
> seems to have languished and is very different from the SBCL version,
> which seems to be the canonical one.  I think it would be unlikely for
> SBCL to keep it up-to-date with CMUCL. :-)

The cclan version is a direct (though distant) ancestor of the one in
SBCL: nothing has been done to it since I put it in SBCL.

If someone wanted to become 'cmucl maintainer', for want of a better
word, for asdf-install, I'd be happy to resuscitate the cclan version
so that they could get cvs hacking privileges from the cclan admins.
(This offer also avilable to hackers of other implementations: openmcl
or clisp or whoever).  In SBCL we already sync asdf itself directly
with the cclan version, so it wouldn't hurt to do similarly for
asdf-install.

Some factoring of the unportable bits in asdf-install would probably
be a win.  A brief scan says we should be concerned about (a) getting
a network connection, (b) stream encodings (we cheat with line
endings, and we expect to be able to send arbitrary binary data over a
character stream), and (c) a raft of good-for-sbcl assumptions about
pathnames and similar.  None of which are unfixable (and (b) isn't an
issue for CMUCL anyway), but it'd be good to expose them.

-dan

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Kleiner | 19 Dec 2003 04:00
Picon
Favicon

asdf example sought

Hi,

I am tinkering with getting cl-http to compile with sbcl using
asdf.  A part of this involves getting defsystem declarations 
translated into asdf's .asd file.

I am having hard time doing it, as the source tree structure
is fairly complex and my asdf does not seem to understand portable
*;**:blah.lisp path designation.

All suggestions are welcome, as are suggestions on why this 
cannot or should not be done (not the right tool for the job, etc)

Thank you,

David

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Permalink | Reply | 4 comments |
headers
Rahul Jain | 19 Dec 2003 04:05

Re: asdf example sought

David Kleiner <kleiner <at> panix.com> writes:

> I am having hard time doing it, as the source tree structure
> is fairly complex and my asdf does not seem to understand portable
> *;**:blah.lisp path designation.

I think WILD-MODULEs are in standard ASDF. Maybe they can be extended to
support this kind of thing, but I don't get why you'd be compiling a
smattering of files from all different dirs as part of the same
module. That would imply that all those files have dependencies on
another module or that all those files work together to provide
something another module needs. Seems like the directory structure got
inverted somewhere.

--

-- 
Rahul Jain
rjain <at> nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Permalink | Reply | 0 comments |
headers
Christophe Rhodes | 19 Dec 2003 11:48
Picon
Picon
Favicon

Re: asdf example sought

David Kleiner <kleiner <at> panix.com> writes:

> I am tinkering with getting cl-http to compile with sbcl using
> asdf.  A part of this involves getting defsystem declarations 
> translated into asdf's .asd file.
>
> I am having hard time doing it, as the source tree structure
> is fairly complex and my asdf does not seem to understand portable
> *;**:blah.lisp path designation.
>
> All suggestions are welcome, as are suggestions on why this 
> cannot or should not be done (not the right tool for the job, etc)

There are two ways for asdf to find its files, in general.  The first,
most commonly used (on Unix, at least), is to organize one's system to
reflect the filesystem, and have asdf do pathname merging relative to
the truename of the .asd system file.  So, under this scheme, we have
something like
  (defsystem foo
    :components
    ((:module bar
       :components (:file "baz"))
     (:file "quux" :depends-on (bar))))
which defines a system that looks like
  bar/baz.lisp
  quux.lisp
relative to the .asd file, where compiling quux.lisp depends on
loading the BAR module.

While this is terribly convenient for new software, it's perfectly
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Barlow | 19 Dec 2003 12:06

Re: asdf example sought

Christophe Rhodes <csr21 <at> cam.ac.uk> writes:

> While this is terribly convenient for new software, it's perfectly
> plausible that it doesn't work so well for legacy software with its
> own ideas of filesystem layout.  So the :pathname option to components
> can be used to override this default.

What he says, but using different words:

It seems that some people come to asdf with the preconception that a
component name is a pathname.  This is not the case.  The pathname of
a component is notionally independent of the component name, but if
left unset (as is the normal way of working) it is defaulted according
to certain rules which involve the component name and do the probably
obvious thing.

-dan

--

-- 

 http://web.metacircles.com/ - Open Source software development and support
Permalink | Reply | 1 comment |
headers
David Kleiner | 20 Dec 2003 00:23
Picon
Favicon

Re: asdf example sought

On Fri, Dec 19, 2003 at 11:06:10AM +0000, Daniel Barlow wrote:
> Christophe Rhodes <csr21 <at> cam.ac.uk> writes:
> 
> > While this is terribly convenient for new software, it's perfectly
> > plausible that it doesn't work so well for legacy software with its
> > own ideas of filesystem layout.  So the :pathname option to components
> > can be used to override this default.
> 
> What he says, but using different words:
> 
> It seems that some people come to asdf with the preconception that a
> component name is a pathname.  This is not the case.  The pathname of
> a component is notionally independent of the component name, but if
> left unset (as is the normal way of working) it is defaulted according
> to certain rules which involve the component name and do the probably
> obvious thing.
> 
> 
> -dan
> 
> -- 
> 

Thank you for the pointers - cl-http's sources are split into common and
implementation-specific areas so it will take some work to convert its
portability ideas into what asdf is intended for.

David

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane