forked from cosmos72/twin
-
Notifications
You must be signed in to change notification settings - Fork 0
/
BUGS
56 lines (42 loc) · 2.45 KB
/
BUGS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
Known bugs and problems:
* `./configure [OPTIONS]' sometimes misdetects which variant of `echo' to use
The effect is an error during `make' that looks as follows:
[...]
building .depend
building .modules
[...]
.modules:1: *** missing separator. Stop.
and if you manually inspect the contents of any file `.modules'
generated by `./configure [OPTIONS]', you will notice that a lot of
lines start with `-e'
The workaround is to delete all files `.depend' and `.modules' or,
better yet, delete all the unpacked sources and start with a clean
copy of twin, then:
1) run `./configure [OPTIONS]'
2) _before_ running `make', edit the file `makeautoconf' end replace
the reference to `echo -e' with `/bin/echo -e'
3) run normally the rest of commands: `make', `make install' etc.
* after `./configure [OPTIONS]' you should `make' in the top-level directory,
as `make' in a subdirectory may fail to properly update dependencies.
This is not a bug in twin, but rather a kind of dependency that
GNU `make' misses.
Let's try to explain (hoping GNU `make' authors read this ;-) ) :
running top-level `./configure [OPTIONS]' generates a new `conf/conf.auto',
which in turn is used to generate `conf/conf.current', which in turn is
used to generate each subdirectory's `.modules'.
Both `conf/conf.current' and `.modules' are included by all Makefiles.
File `.modules' contains data that depends on data from `conf/conf.current',
and infact `.modules' has `conf/conf.current' in its prerequisites.
The problem is: `make' realizes it must rebuild `conf/conf.current'
after a new `conf/conf.auto' is generated, and rebuilds it,
but then IMMEDIATELY also rebuilds `.modules', which get generated
with out-of-date contents since it uses variables from `make' memory,
instead of re-reading `conf/conf.current' to update the variables.
What `make' should do is to re-read the newly generated `conf/conf.current'
(possibly by re-executing `make'), BEFORE generating `.modules', since
`.modules' depends on `conf/conf.current'.
Instead the rule currently used by `make' is this: it first tries
to update all Makefiles (and files included by them) in a single shot,
and only at the end re-executes `make' to read the updated Makefiles.
In this way, dependencies between Makefiles (and files included by them)
may be --- and infact are --- incorrectly used.