Fortran 90 modules

68 views
Skip to first unread message

Jed Brown

unread,
Jul 7, 2010, 5:19:33 PM7/7/10
to tup-users
For Fortran 90, the set of output files is dependent on the contents of
the document (and perhaps the compiler in use). Even if I specify these
manually, as in this Tupfile:

PETSC_DIR=/home/jed/petsc
PETSC_ARCH=ompi
: petscsysmod.F |> mpif90 -c -I$(PETSC_DIR)/$(PETSC_ARCH)/include -I$(PETSC_DIR)/include %f |> %B.o | petscsysdef.mod petscsys.mod

I'm getting

$ gdb --args tup upd
No symbol table is loaded. Use the "file" command.
Breakpoint 1 (PetscError) pending.
Reading symbols from /home/jed/usr/bin/tup...done.
(gdb) b fprintf
Breakpoint 2 at 0x402308
(gdb) r
Starting program: /home/jed/usr/bin/tup upd
[Thread debugging using libthread_db enabled]
[ tup ] Scanning filesystem...0.094s
[ tup ] No tup.config changes.
[ tup ] No Tupfiles to parse.
[New Thread 0x7ffff7864710 (LWP 2043)]
[ tup ] No files to delete.
[Thread 0x7ffff7864710 (LWP 2043) exited]
[ tup ] Executing Commands...
[New Thread 0x7ffff7864710 (LWP 2044)]
[ 0/1 ] mpif90 -c -I/home/jed/petsc/ompi/include -I/home/jed/petsc/include petscsysmod.F
[New Thread 0x7ffff7063710 (LWP 2045)]
[Thread 0x7ffff7063710 (LWP 2045) exited]
[Switching to Thread 0x7ffff7864710 (LWP 2044)]

Breakpoint 2, 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
#1 0x00000000004103c5 in missing_output (tupid=5, data=0x7ffff7863b70) at db.c:3741
#2 0x000000000041003e in compare_list_tree (a=0x68de70, b=0x7ffff7863b80, data=0x7ffff7863b70, extra_a=0x41025c <extra_output>, extra_b=0x410367 <missing_output>) at db.c:3646
#3 0x0000000000410455 in tup_db_check_actual_outputs (cmdid=8, writelist=0x68de70) at db.c:3762
#4 0x0000000000460946 in update_write_info (cmdid=8, dt=1, dfd=13, debug_name=0x6cfc10 "mpif90 -c -I/home/jed/petsc/ompi/include -I/home/jed/petsc/include petscsysmod.F", info=0x6d1cb8, warnings=0x68ef4c, entrylist=0x68de70) at file.c:423
#5 0x000000000045fa1e in write_files (cmdid=8, dt=1, dfd=13, debug_name=0x6cfc10 "mpif90 -c -I/home/jed/petsc/ompi/include -I/home/jed/petsc/include petscsysmod.F", info=0x6d1cb8, warnings=0x68ef4c) at file.c:108
#6 0x000000000041822b in update (n=0x6ce0c0, s=0x6d1ca0) at updater.c:920
#7 0x0000000000417b1e in update_work (arg=0x6ccbf0) at updater.c:736
#8 0x00007ffff7bc7cb0 in start_thread () from /lib/libpthread.so.0
#9 0x00007ffff79337ad in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()
(gdb) c
Continuing.
Error: Expected to write to file 'petscsysmod.o' from cmd 8 but didn't

Breakpoint 2, 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
#1 0x00000000004103c5 in missing_output (tupid=6, data=0x7ffff7863b70) at db.c:3741
#2 0x000000000041003e in compare_list_tree (a=0x68de70, b=0x7ffff7863b80, data=0x7ffff7863b70, extra_a=0x41025c <extra_output>, extra_b=0x410367 <missing_output>) at db.c:3646
#3 0x0000000000410455 in tup_db_check_actual_outputs (cmdid=8, writelist=0x68de70) at db.c:3762
#4 0x0000000000460946 in update_write_info (cmdid=8, dt=1, dfd=13, debug_name=0x6cfc10 "mpif90 -c -I/home/jed/petsc/ompi/include -I/home/jed/petsc/include petscsysmod.F", info=0x6d1cb8, warnings=0x68ef4c, entrylist=0x68de70) at file.c:423
#5 0x000000000045fa1e in write_files (cmdid=8, dt=1, dfd=13, debug_name=0x6cfc10 "mpif90 -c -I/home/jed/petsc/ompi/include -I/home/jed/petsc/include petscsysmod.F", info=0x6d1cb8, warnings=0x68ef4c) at file.c:108
#6 0x000000000041822b in update (n=0x6ce0c0, s=0x6d1ca0) at updater.c:920
#7 0x0000000000417b1e in update_work (arg=0x6ccbf0) at updater.c:736
#8 0x00007ffff7bc7cb0 in start_thread () from /lib/libpthread.so.0
#9 0x00007ffff79337ad in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()
(gdb) c
Continuing.
Error: Expected to write to file 'petscsysdef.mod' from cmd 8 but didn't

Breakpoint 2, 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
#1 0x00000000004103c5 in missing_output (tupid=7, data=0x7ffff7863b70) at db.c:3741
#2 0x000000000041003e in compare_list_tree (a=0x68de70, b=0x7ffff7863b80, data=0x7ffff7863b70, extra_a=0x41025c <extra_output>, extra_b=0x410367 <missing_output>) at db.c:3646
#3 0x0000000000410455 in tup_db_check_actual_outputs (cmdid=8, writelist=0x68de70) at db.c:3762
#4 0x0000000000460946 in update_write_info (cmdid=8, dt=1, dfd=13, debug_name=0x6cfc10 "mpif90 -c -I/home/jed/petsc/ompi/include -I/home/jed/petsc/include petscsysmod.F", info=0x6d1cb8, warnings=0x68ef4c, entrylist=0x68de70) at file.c:423
#5 0x000000000045fa1e in write_files (cmdid=8, dt=1, dfd=13, debug_name=0x6cfc10 "mpif90 -c -I/home/jed/petsc/ompi/include -I/home/jed/petsc/include petscsysmod.F", info=0x6d1cb8, warnings=0x68ef4c) at file.c:108
#6 0x000000000041822b in update (n=0x6ce0c0, s=0x6d1ca0) at updater.c:920
#7 0x0000000000417b1e in update_work (arg=0x6ccbf0) at updater.c:736
#8 0x00007ffff7bc7cb0 in start_thread () from /lib/libpthread.so.0
#9 0x00007ffff79337ad in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()
(gdb) c
Continuing.
Error: Expected to write to file 'petscsys.mod' from cmd 8 but didn't

Breakpoint 2, 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
#1 0x0000000000418332 in update (n=0x6ce0c0, s=0x6d1ca0) at updater.c:936
#2 0x0000000000417b1e in update_work (arg=0x6ccbf0) at updater.c:736
#3 0x00007ffff7bc7cb0 in start_thread () from /lib/libpthread.so.0
#4 0x00007ffff79337ad in clone () from /lib/libc.so.6
#5 0x0000000000000000 in ?? ()
(gdb) c
Continuing.
*** Killed by signal 11 (Segmentation fault)

Breakpoint 2, 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6


Note that the compiler really is producing these files so I don't
understand the SEGV.

$ ls
petscsysmod.F Tupfile
$ mpif90 -c -I/home/jed/petsc/ompi/include -I/home/jed/petsc/include petscsysmod.F
$ ls
petscsysdef.mod petscsys.mod petscsysmod.F petscsysmod.o Tupfile

Any suggestions on debugging this? How about handling the module files?
(There can be an arbitrary number of these, defined by the contents of
the file. Blame the Fortran committee for this horrible, horrible
design.)

Jed

Mike Shal

unread,
Jul 7, 2010, 7:30:43 PM7/7/10
to tup-...@googlegroups.com
On 7/7/10, Jed Brown <j...@59a2.org> wrote:
> For Fortran 90, the set of output files is dependent on the contents of
> the document (and perhaps the compiler in use). Even if I specify these
> manually, as in this Tupfile:
>
> PETSC_DIR=/home/jed/petsc
> PETSC_ARCH=ompi
> : petscsysmod.F |> mpif90 -c -I$(PETSC_DIR)/$(PETSC_ARCH)/include -I$(PETSC_DIR)/include %f |> %B.o | petscsysdef.mod petscsys.mod
>
> I'm getting
>
(snip)

> Error: Expected to write to file 'petscsys.mod' from cmd 8 but didn't

Is mpif90 statically linked on your system? I just installed it on
mine and built a hello-world fortran program and it properly detected
the .o file that was created. The LD_PRELOAD method only works on
programs that dynamically link libc, so that would be one cause for
that error (another would be they're using a funky library call that
isn't wrapped yet).

>
> Breakpoint 2, 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
> (gdb) bt
> #0 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
> #1 0x0000000000418332 in update (n=0x6ce0c0, s=0x6d1ca0) at updater.c:936
> #2 0x0000000000417b1e in update_work (arg=0x6ccbf0) at updater.c:736
> #3 0x00007ffff7bc7cb0 in start_thread () from /lib/libpthread.so.0
> #4 0x00007ffff79337ad in clone () from /lib/libc.so.6
> #5 0x0000000000000000 in ?? ()
> (gdb) c
> Continuing.
> *** Killed by signal 11 (Segmentation fault)
>
> Breakpoint 2, 0x00007ffff78b1b80 in fprintf () from /lib/libc.so.6
>
>
> Note that the compiler really is producing these files so I don't
> understand the SEGV.

I'm not sure why it would segfault either. Is it only for this
particular fortran file (or group of files?) If so, can you send one
my way? Here's the hello-world program I found that compiled (and runs
if I fully link it) -

$ cat Tupfile


PETSC_DIR=/home/jed/petsc
PETSC_ARCH=ompi
: petscsysmod.F |> mpif90 -c -I$(PETSC_DIR)/$(PETSC_ARCH)/include
-I$(PETSC_DIR)/include %f |> %B.o

$ cat petscsysmod.F
program HelloWorld
write (*,*) 'Hello, world!' ! This is an inline comment
end program HelloWorld

(I left the Tupfile mostly as you had it, except for the .mod outputs
since this file doesn't create those)

>
> Any suggestions on debugging this? How about handling the module files?
> (There can be an arbitrary number of these, defined by the contents of
> the file. Blame the Fortran committee for this horrible, horrible
> design.)

Unfortunately if there's one thing I have less experience with than
LaTeX, it's Fortran :). At one point I had been playing around with a
way to allow programs to create arbitrary files at runtime, but I
haven't been able to finish it (there are some tricky cases that
creates). Also, that wouldn't help with dependencies between .mod
files, if you have to build certain .f files before others (is that an
issue?)

-Mike

Jed Brown

unread,
Jul 7, 2010, 7:44:16 PM7/7/10
to Mike Shal, tup-...@googlegroups.com
On Wed, 7 Jul 2010 19:30:43 -0400, Mike Shal <mar...@gmail.com> wrote:
> Is mpif90 statically linked on your system? I just installed it on
> mine and built a hello-world fortran program and it properly detected
> the .o file that was created. The LD_PRELOAD method only works on
> programs that dynamically link libc, so that would be one cause for
> that error (another would be they're using a funky library call that
> isn't wrapped yet).

mpif90 is a bash wrapper around gfortran, using gfortran directly (after
adding the MPI paths) works fine. I can package up a test case if
necessary.

> Unfortunately if there's one thing I have less experience with than
> LaTeX, it's Fortran :). At one point I had been playing around with a
> way to allow programs to create arbitrary files at runtime, but I
> haven't been able to finish it (there are some tricky cases that
> creates). Also, that wouldn't help with dependencies between .mod
> files, if you have to build certain .f files before others (is that an
> issue?)

It is an issue for some projects, Fortran doesn't provide a good way to
automatically determine this, CMake parses the files and produces a
manual dependency graph.

Jed

Mike Shal

unread,
Jul 7, 2010, 7:59:30 PM7/7/10
to Jed Brown, tup-...@googlegroups.com
On 7/7/10, Jed Brown <j...@59a2.org> wrote:
> On Wed, 7 Jul 2010 19:30:43 -0400, Mike Shal <mar...@gmail.com> wrote:
> > Is mpif90 statically linked on your system? I just installed it on
> > mine and built a hello-world fortran program and it properly detected
> > the .o file that was created. The LD_PRELOAD method only works on
> > programs that dynamically link libc, so that would be one cause for
> > that error (another would be they're using a funky library call that
> > isn't wrapped yet).
>
>
> mpif90 is a bash wrapper around gfortran, using gfortran directly (after
> adding the MPI paths) works fine. I can package up a test case if
> necessary.

Can you send the bash wrapper? On my machine, mpif90 is symlinked to
opal_wrapper, which is an ELF executable. (And when I run mpif90, it
tells me that it is i686-pc-linux-gnu-gfortran).

>
>
> > Unfortunately if there's one thing I have less experience with than
> > LaTeX, it's Fortran :). At one point I had been playing around with a
> > way to allow programs to create arbitrary files at runtime, but I
> > haven't been able to finish it (there are some tricky cases that
> > creates). Also, that wouldn't help with dependencies between .mod
> > files, if you have to build certain .f files before others (is that an
> > issue?)
>
>
> It is an issue for some projects, Fortran doesn't provide a good way to
> automatically determine this, CMake parses the files and produces a
> manual dependency graph.

Doh - tup doesn't have any domain specific knowledge, or
infrastructure in place to parse files for their dependencies before
building them. All the deps come either explicitly from the Tupfiles,
or implicitly by actually running the commands based on their file
accesses. Once tup is running a command, it's too late for it to see
that it needed a file that another command can build (like a .mod file
from another source), which is why you'd get an error in that case.
So, it may be that tup and fortran don't go well together. I'd still
like to get the segfault resolved, though, since that just shouldn't
happen.

-Mike

Jed Brown

unread,
Jul 7, 2010, 8:08:51 PM7/7/10
to Mike Shal, tup-...@googlegroups.com
On Wed, 7 Jul 2010 19:59:30 -0400, Mike Shal <mar...@gmail.com> wrote:
> Can you send the bash wrapper? On my machine, mpif90 is symlinked to
> opal_wrapper, which is an ELF executable. (And when I run mpif90, it
> tells me that it is i686-pc-linux-gnu-gfortran).

Sorry, I forgot that OMPI doesn't do bash wrappers, I have the same setup as you:

/usr/bin/opal_wrapper: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

I haven't looked to see how this actually spawns gfortran, maybe that's
the problem? It works fine with MPICH2's mpif90 wrapper (which is
actually a bash script).

> Doh - tup doesn't have any domain specific knowledge, or
> infrastructure in place to parse files for their dependencies before
> building them. All the deps come either explicitly from the Tupfiles,
> or implicitly by actually running the commands based on their file
> accesses. Once tup is running a command, it's too late for it to see
> that it needed a file that another command can build (like a .mod file
> from another source), which is why you'd get an error in that case.
> So, it may be that tup and fortran don't go well together.

Or we have to live with generated Tupfiles...

Jed

Mike Shal

unread,
Jul 7, 2010, 10:38:31 PM7/7/10
to Jed Brown, tup-...@googlegroups.com
On 7/7/10, Jed Brown <j...@59a2.org> wrote:
> On Wed, 7 Jul 2010 19:59:30 -0400, Mike Shal <mar...@gmail.com> wrote:
> > Can you send the bash wrapper? On my machine, mpif90 is symlinked to
> > opal_wrapper, which is an ELF executable. (And when I run mpif90, it
> > tells me that it is i686-pc-linux-gnu-gfortran).
>
>
> Sorry, I forgot that OMPI doesn't do bash wrappers, I have the same setup as you:
>
> /usr/bin/opal_wrapper: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
>
> I haven't looked to see how this actually spawns gfortran, maybe that's
> the problem? It works fine with MPICH2's mpif90 wrapper (which is
> actually a bash script).

Possibly, though I don't know why mine would behave differently from
yours. I was hoping I could reproduce it here. Can you also try the
ptrace branch to see if that works? The LD_PRELOAD method uses some
environment variables and an open socketpair to communicate back and
forth - maybe something in the middle is clearing out the environment
or closing the open file descriptors. The ptrace branch doesn't do
that (at least not in a way that the child process can affect it), so
it may have better success.

>
>
> > Doh - tup doesn't have any domain specific knowledge, or
> > infrastructure in place to parse files for their dependencies before
> > building them. All the deps come either explicitly from the Tupfiles,
> > or implicitly by actually running the commands based on their file
> > accesses. Once tup is running a command, it's too late for it to see
> > that it needed a file that another command can build (like a .mod file
> > from another source), which is why you'd get an error in that case.
> > So, it may be that tup and fortran don't go well together.
>
>
> Or we have to live with generated Tupfiles...

True 'nuff. I think long term I was going to try to allow running
external scripts in a Tupfile to generate rules (so it could be in
shell or python or whatever instead of tup's crappy language). That
script would be instrumented similar to the actual commands to track
file accesses in order to determine when it needs to be re-executed.
The only real difference would be it generates a list of :-rules
instead of actual files. I have no idea how feasible that will be,
though.

-Mike

Ryan Rusaw

unread,
Jul 14, 2010, 10:55:48 PM7/14/10
to tup-users
I threw together a patch that adds support for inline Lua in Tupfiles,
any interest at all? It simply executes the lua script and then
replaces its text in the Tupfile read buffer with its own return
value. It then continues parsing the new read buffer.

Ryan

Mike Shal

unread,
Jul 15, 2010, 12:18:08 AM7/15/10
to tup-...@googlegroups.com

Sure, can you attach the patch or publish a git repo somewhere?

Thanks,
-Mike

Ryan Rusaw

unread,
Jul 15, 2010, 12:51:54 AM7/15/10
to tup-users
I uploaded a patch to the files section of the group.

Ryan

Jed Brown

unread,
Jul 15, 2010, 5:04:48 AM7/15/10
to Ryan Rusaw, tup-users
On Wed, 14 Jul 2010 19:55:48 -0700 (PDT), Ryan Rusaw <rru...@gmail.com> wrote:
> I threw together a patch that adds support for inline Lua in Tupfiles,
> any interest at all? It simply executes the lua script and then
> replaces its text in the Tupfile read buffer with its own return
> value. It then continues parsing the new read buffer.

Very cool.

Does it make sense for Lua interpreting to be enabled recursively, or
would it be acceptable to be strictly single-expansion (easier to reason
about and less likely to accidentally create an infinite loop)?

What is the canonical way to have Tupfiles re-parsed? This is highly
relevant when they can execute arbitrary code, and I (personally) think
warrants a command line option.

Jed

Mike Shal

unread,
Jul 15, 2010, 10:25:33 AM7/15/10
to tup-...@googlegroups.com
On 7/15/10, Jed Brown <j...@59a2.org> wrote:
> On Wed, 14 Jul 2010 19:55:48 -0700 (PDT), Ryan Rusaw <rru...@gmail.com> wrote:
> > I threw together a patch that adds support for inline Lua in Tupfiles,
> > any interest at all? It simply executes the lua script and then
> > replaces its text in the Tupfile read buffer with its own return
> > value. It then continues parsing the new read buffer.
>
>
> Very cool.
>
> Does it make sense for Lua interpreting to be enabled recursively, or
> would it be acceptable to be strictly single-expansion (easier to reason
> about and less likely to accidentally create an infinite loop)?

I'm not sure what you mean here - or is this a question for Ryan?

>
> What is the canonical way to have Tupfiles re-parsed? This is highly
> relevant when they can execute arbitrary code, and I (personally) think
> warrants a command line option.

If you have a Tupfile like this:
1) include_rules
2) include foo.tup
3) : *.c |> ... |>
4) : bar/*.c |> ... |>
5) var-@(BLAH) += ...

Line 1) will cause that Tupfile to be re-parsed anytime a Tuprules.tup
file is created/modified/removed in the current directory or any
directory up to where .tup exists. Line 2) causes that Tupfile to be
re-parsed if foo.tup is modified. Lines 3) and 4) cause that Tupfile
to be dependent on the directories "." and "bar", respectively.
(Though I think the Tupfile is always dependent on the "." directory
anyway). A directory is considered "modified" if a file is created or
destroyed in that directory. So if you add a new file in "." or
"bar/", then the Tupfile is re-parsed. Finally, any use of an
@-variable creates a dependency on that variable from the tup.config
(as in line 5).

The directory-level dependencies form a DAG that is mostly separate
from the regular DAG (like .c -> .o -> binary). In this example, if we
need to re-parse bar/Tupfile for any reason, then the ./Tupfile would
also be re-parsed. This could be necessary if bar/Tupfile is changed
to auto-generate a new .c file, which ./Tupfile is wild-carding on.
This case could be optimized to do short-circuiting, but right now it
just re-parses any Tupfile that satisfies the rules above, and
Tupfiles that depend on it.

Since lua (or other scripting languages) can presumably do their own
open()s and opendir()s to cause additional file and directory level
dependencies, that's why I was suggesting that the parsing stage would
need to be instrumented to catch all of those. Otherwise you might
change some utility script that gets included from the main script,
but that dependency would be lost.

What command-line option are you suggesting?

-Mike

Jed Brown

unread,
Jul 15, 2010, 11:12:37 AM7/15/10
to Mike Shal, tup-...@googlegroups.com
On Thu, 15 Jul 2010 10:25:33 -0400, Mike Shal <mar...@gmail.com> wrote:
> On 7/15/10, Jed Brown <j...@59a2.org> wrote:
> > Does it make sense for Lua interpreting to be enabled recursively, or
> > would it be acceptable to be strictly single-expansion (easier to reason
> > about and less likely to accidentally create an infinite loop)?
>
> I'm not sure what you mean here - or is this a question for Ryan?

Mostly for Ryan, regarding what is probably a trivial implementation
choice, but has long-term consequences.

Thanks for this explanation.

> Since lua (or other scripting languages) can presumably do their own
> open()s and opendir()s to cause additional file and directory level
> dependencies, that's why I was suggesting that the parsing stage would
> need to be instrumented to catch all of those. Otherwise you might
> change some utility script that gets included from the main script,
> but that dependency would be lost.
>
> What command-line option are you suggesting?

Just a "don't trust your last analysis" tup upd --reparse, but perhaps
touch Tupfile would be sufficient (because it shouldn't have to be done)
if Tup can reliably track all of Lua's file accesses (and you're not
doing something weird like generating new file names or variables based
on e.g. date or /dev/random).

Jed

Mike Shal

unread,
Jul 16, 2010, 12:02:09 AM7/16/10
to Jed Brown, tup-...@googlegroups.com

It might be handy to have a shell script or debug feature that does a
'tup upd', then touches every Tupfile and re-builds to make sure no
other commands are executed. This would only be useful in debugging
tup itself though, not a project that you're using tup to build. I
don't want to make that as a standard option to 'upd' though since it
might suggest to people that it is necessary to do it on occasion
"just to be sure" (like one would do a "clean" build in make). I'd
rather just have a working build system.

I agree there are weird things you can do to make the builds
irreproducible, like basing file accesses from the date and such. This
would cause problems with any file-based build system though, so I
don't see what tup could do about it other than to discourage doing
such crazy things.

-Mike

Jed Brown

unread,
Jul 19, 2010, 5:21:06 AM7/19/10
to Mike Shal, tup-...@googlegroups.com
On Fri, 16 Jul 2010 00:02:09 -0400, Mike Shal <mar...@gmail.com> wrote:
> I agree there are weird things you can do to make the builds
> irreproducible, like basing file accesses from the date and such. This
> would cause problems with any file-based build system though, so I
> don't see what tup could do about it other than to discourage doing
> such crazy things.

It depends where "configure" functionality ends up going. If the
configure stage produces a makefile (or other build files) then you
re-run configure after changing your environment. But if instead of
generating build files, you rely on tup to cache this stuff, you need a
way to force a full reevaluation.

Note that configuration is quite expensive, it involves compiling and
running programs, perhaps through a batch submission system.

Jed

Reply all
Reply to author
Forward
0 new messages