dolfin team mailing list archive

["Åsmund Ødegård" <aasmund@xxxxxxxxx>]

Hi Andy,

thanks for your report :)

On Mon, Mar 10, 2008 at 10:07 PM, Andy Ray Terrel <aterrel@xxxxxxxxxxxx>
wrote:

> I am having trouble with scons trying to find UMFPACK for me on my mac
> laptop and am trying to debug how it configures itself.  When I look at
> dolfin/scons/simula-scons/simula_scons/pkgconggenerators/umfpack.py this
> codes adds a bunch of directories and looks for umfpack.h, libumfpack.a,
> amd.h and so on.  If it can't find these guys it raises an error saying
> so and similarly if it cannot compile the test programs.


You could actually run that script standalone - just cd in there and do
'python umfpack.py'  - that might yield some extra information... Maybe you
can try that and report?

Now, this script is especially messy due to the many variants umfpack can be
installed in - but I thought we had osx covered (as I'm on osx myself...).

 But, when I
> run scons with the UMFPACK_DIR set to a directory with the lib and
> include/suitesparse it gives me an very ambiguous error not found in the
> umfpack.py file: "Unable to generate a suitable pkg-config file for
> umfpack."


That's right. The script is meant for standalone use - when running through
scons, the exceptions are captured, and unfortunately I don't think we put
the errormessage in our secret log yet...  I'll have a look and see if it's
easy to fix

Also I can't find anything like a log file telling me what
> the error could be; the only logfiles I find tell me what was found but
> not what wasn't.  I don't really know scons at all and haven't spent
> time learning the whole system, does anyone have some tips for debugging
> this sort of thing?


Sure. First, knowing scons won't help you much, as this is where we try to
help scons. There are some ongoing developments in main scons, though, that
we hopefully can revert to in the future. Second, while knowing scons will
certainly help, it is not the intention that all dolfin-developers should
know scons!

>
>
> Some other questions I have are:
> * Is there a way not to go through the configure process when you change
> a bit of the code, ie just make not configure and make?


Not at the moment. As most of the configure stuff is cached in the
pkg-config files, the configure part should be relatively light on
subsequent invocations, but clearly simula-scons should be developed further
in this respect.


> * How does scons tell that a file has changed?  I tried changing the
> code a bit and it doesn't seem to be spitting out all the g++ commands
> as I expected for the specific files.
>

This is actually an area where scons is supposed to be quite good. It use
MD5 sums of files to detect changes. Could you say a bit more about what you
changed, and what happend?

Below is some data for my current problem:
>
> aterrel@andy-terrels-computer:/usr/local/src/dolfin$ uname -v -r
> 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007;
> root:xnu-792.25.20~1/RELEASE_I386
> aterrel@andy-terrels-computer:/usr/local/src/dolfin$ find /sw/lib -name
> *umfpack*
> /sw/lib/libumfpack.a
>

aha - I see... We are testing
$UMFPACK_DIR/{suitesparse,lib/suitesparse,suitespare/lib} among many others,
but we are not testing just $UMFPACK_DIR/lib.

I'll check in a fix for this!

aterrel@andy-terrels-computer:/usr/local/src/dolfin$ find /sw/include
> -name *umfpack*
> /sw/include/suitesparse/umfpack.h
>

Should be ok.


> <snip>
> aterrel@andy-terrels-computer:/usr/local/src/dolfin$ find /sw/include
> -name *amd*
> /sw/include/suitesparse/amd.h
>

Ditto


> <snip>
> aterrel@andy-terrels-computer:/usr/local/src/dolfin$ find /sw/lib -name
> *amd*
> /sw/lib/libamd.a
>

And same problem again...



> aterrel@andy-terrels-computer:/usr/local/src/dolfin$ UMFPACK_DIR=/sw/
> scons
> scons: Reading SConscript files ...
> <snip>
> Checking for umfpack... no (pkg-config file not found)
>  Trying to generate pkg-config file for umfpack... failed
>  *** Unable to generate a suitable pkg-config file for umfpack.
>  *** If umfpack is present on your system, try setting the UMFPACK_DIR
>  *** environment variable to the directory where umfpack is installed.
>  *** UMFPACK_DIR is currently set to /sw/
> <snip>
>

Hope this made things even less or more confusing :)

best regards,
Åsmund