Re: Is Repository broken?

[Steven Knight]

> 1/ I complained of not being able to have Link and repository work together.
> I did run more tests. After spending hours in the debugger try to figure out
> what the problem is, I finally decided to have the simplest example possible

An excellent approach.

> C:/Documents and Settings/nadim/Desktop/cons-test/simple repository test
> ¦   construct.cons
> ¦       ****************************************************** 
> ¦       # couldn't come with a simpler construct
> ¦       $CONS = new cons(ENV => {%ENV});
> ¦       
> ¦       Repository 'c:/Documents and Settings/nadim/Desktop/cons-test/=> ¦
> =>simple repository test/repository' ;
> ¦       
> ¦       $CONS->Objects('main.c') ;
> ¦       ****************************************************** 
> ¦   main.c
> ¦
> +---repository
>         main.c
        .
        .
        .
> ?? cl /nologo /c main.c\repository\main.c /Fomain.obj
>                  ^^^^^^^^^^^^^^^^^^^^^^^^
>                  where is this coming from?

Good question.

Thank you for the very clear test case.  I was able to reproduce this
problem easily.

The problem is: you're trying to use a Repository from underneath the
source tree.  A Repository should live *outside* of the source tree.

Link() is for variant builds *within* the source tree.

Repository() is for fetching sources and/or objects into your source
tree from an *external* repository.

(No, I didn't realize this problem existed when trying to specify a
Repository from a directory underneath the source tree.  Yes, we should
either find a way to fix this, or provide a better error message and
document the restriction.)

> I do no complain without testing so I spend 4 hours in the debugger (again)
> trying to understand the bowels of cons. The problem seems to be in
> dir::path.  (which works as programmed but not as intended, which I can't
> comment as nothig describes how it should work)
> 
> Not strange I get errors with Link and Repository if Repository does not
> work.

It's usually useful to make a distinction between a feature "not
working" and finding a specific, non-intended configuration that falls
outside of the original design.

If you move your Construct file down into a subdirectory, for example,
so that the repository directory is *outside* of the source tree, you'll
find that it works very much as intended:

        $ cat subdir/Construct
        $CONS = new cons(ENV => {%ENV});
        
        Repository('/home/knight/x/repository');
        
        $CONS->Program('main', 'main.c');
        $ cat repository/main.c
        int
        main(int argc, char *argv[])
        {
                printf("repository/main.c\n");
                exit(0);
        }
        $ cons -f subdir/Construct .
        cc -c /home/knight/x/repository/main.c -o main.o
        cc -o main main.o
        $ subdir/main
        repository/main.c
        $ 

> Now I would have liked to run cons on a test suit or on the examples from
> cons cookbook ;-)

Cough.  An extensive test suite exists for Cons.  It even checks to make
sure that Repository functionality works and--guess what?  It's even
available for download from the Cons web site!  (Hint:  Look for the
cons-test package... :-)

> I use : $CVS_id = '$Id: cons.pl,v 1.173 2001/11/05 17:29:24 knight Exp $ ';
> 
> This version fixed the problem with dependencies in Linked directories.
> Isn't it a pity to let people download a version with errors when a better
> version exists!

I agree.  Rajesh, 2.3.1, or 2.4.0...?

> I am very surprised, I can conceive that the writer of cons did not have a
> test suit or even missed some tests but isn't anyone using the advanced
> features of cons?

Yes, people are using Repository.  But not in the rather unusual way
you're trying to use it.

        --SK