Comprehensive Common Lisp Archive Net

Nikodemus Siivola <tsiivola@...> writes:

> 
>  window.lisp <-- needs SDL
>  render.lisp <-- needs window.lisp if we have SDL
> 

what's wrong with:

:components ((:file "render" #+cl-sdl :depends-on #+cl-sdl ("window"))
     #+cl-sdl(:file "window"))

for more complex things it helps to define modules and condititonally
include those.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen

On 9 Apr 2003, Marco Baringer wrote:

> what's wrong with:
>
> :components ((:file "render" #+cl-sdl :depends-on #+cl-sdl ("window"))
>      #+cl-sdl(:file "window"))

It seems that CL-SDL does not add itself to *features*, and pushing it
there manually doesn't seem much of an improvement over two systems...

> for more complex things it helps to define modules and condititonally
> include those.

Could you give an example? I have a hunch that in the future I will be
depending on the presence of a lot of things, but can actually do without
most of them...

Thanks,

 -- Nikodemus

i'd be curious about this too. it's one of the things which impairs
translating my system descriptions to asdf.


Nikodemus Siivola wrote:
> 
> How should I deal with alternative system configurations with ASDF? My
> system can function both with or without CL-SDL, but the system is slightly
> different when it is not present:
> 
>  window.lisp <-- needs SDL
>  render.lisp <-- needs window.lisp if we have SDL
> 
> Currently I have solved this by having two alternative system definitions,
> detecting the presence of SDL before calling ASDF, and then loading the
> correct system. As far as solutions go it works, but is butt ugly.
> 
> Is there a way to handle this with a single system-definition?
> 
> Cheers,
> 
>   -- Nikodemus

not the original question, but take a situation where i have four system
components a,b,c,d and for the purposes of compiling the system the depandancy is

       a
      / \
      b c
      \ /
       d

which means that the builder needs to specify either a and b, or a and c to
build. on the other hand, when it comes to documenting or releasing, one would
like to specify a and b and c and not have to worry about what
conditionalization has done to the effective expression of the system structure.

...

Nikodemus Siivola wrote:
> 
> On 9 Apr 2003, Marco Baringer wrote:
> 
> > what's wrong with:
> >
> > :components ((:file "render" #+cl-sdl :depends-on #+cl-sdl ("window"))
> >      #+cl-sdl(:file "window"))
> 
> It seems that CL-SDL does not add itself to *features*, and pushing it
> there manually doesn't seem much of an improvement over two systems...
> 
> > for more complex things it helps to define modules and condititonally
> > include those.
> 
> Could you give an example? I have a hunch that in the future I will be
> depending on the presence of a lot of things, but can actually do without
> most of them...
> 
> Thanks,
> 
>  -- Nikodemus
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. http://www.etnus.com
> _______________________________________________
> cclan-list mailing list
> cclan-list@...
> https://lists.sourceforge.net/lists/listinfo/cclan-list

John DeSoi <jdesoi@...> writes:

> I just updated to asdf 1.68 and discovered putting a function in
> *central-registry* no longer works. I noticed that there is a new
> variable *system-definition-search-functions* which I adapted my
> functions to work with. But this symbol is not exported -- is that an
> oversight or is there no longer a supported way to use functions to
> generate the system definition path from the name?

An oversight; it'll be exported in the next version.  Thanks for
pointing this out.  *system-definition-search-functions* is supported
(insofar as free software is ever supported, anyway) and should be
significantly more predictable than putting functions in
*central-registry*


-dan

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources