Configure finished. Do 'make depend && make' to compile Wine.
cd `dirname dlls/__depend__` && make depend make[1]: Entering directory `/opt/dimi/dev/wine/wine/dlls' cd `dirname advapi32/__depend__` && make depend make[2]: Entering directory `/opt/dimi/dev/wine/wine/dlls/advapi32' cd `dirname tests/__depend__` && make depend make[3]: Entering directory `/opt/dimi/dev/wine/wine/dlls/advapi32/tests' ../../../tools/makedep -I../../../../wine.src/dlls/advapi32/tests -I. -I../../../../wine.src/include -I../../../include -C../../../../wine.src/dlls/advapi32/tests registry.c testlist.c ../../../../wine.src/dlls/advapi32/tests/testlist.c: No such file or directory make[3]: *** [depend] Error 1 make[3]: Leaving directory `/opt/dimi/dev/wine/wine/dlls/advapi32/tests' make[2]: *** [tests/__depend__] Error 2 make[2]: Leaving directory `/opt/dimi/dev/wine/wine/dlls/advapi32' make[1]: *** [advapi32/__depend__] Error 2 make[1]: Leaving directory `/opt/dimi/dev/wine/wine/dlls' make: *** [dlls/__depend__] Error 2
On Thu, 12 Dec 2002, Dimitrie O. Paun wrote:
Configure finished. Do 'make depend && make' to compile Wine.
cd `dirname dlls/__depend__` && make depend make[1]: Entering directory `/opt/dimi/dev/wine/wine/dlls' cd `dirname advapi32/__depend__` && make depend make[2]: Entering directory `/opt/dimi/dev/wine/wine/dlls/advapi32' cd `dirname tests/__depend__` && make depend make[3]: Entering directory `/opt/dimi/dev/wine/wine/dlls/advapi32/tests' ../../../tools/makedep -I../../../../wine.src/dlls/advapi32/tests -I. -I../../../../wine.src/include -I../../../include -C../../../../wine.src/dlls/advapi32/tests registry.c testlist.c ../../../../wine.src/dlls/advapi32/tests/testlist.c: No such file or directory
Ah, you're building out of tree too <g>. You need to recompile makedep. For instance:
rm ../../../tools/makedep.o make depend
Now I must say that I wonder why this was not done automatically. Shouldn't the .c.o dependency kick in automatically in tools/Makefile.in? Maybe you can solve this one?
Francois Gouget fgouget@free.fr writes:
Now I must say that I wonder why this was not done automatically. Shouldn't the .c.o dependency kick in automatically in tools/Makefile.in? Maybe you can solve this one?
The depend: target doesn't depend on the tools, because that would slow things down a lot. makedep doesn't change often enough for this to be a real problem; and a make clean will fix it anyway.
On December 12, 2002 11:38 am, Alexandre Julliard wrote:
The depend: target doesn't depend on the tools, because that would slow things down a lot. makedep doesn't change often enough for this to be a real problem; and a make clean will fix it anyway.
Speaking of makedep: we have this non-standard "" vs <> convention for include files, which is (1) potentially confusing, and (2) can cause problems in Winelib apps that have private headers that conflict with names of our headers.
If I understand it correctly, the rationale is to be able to easily segregate the host system headers from the Win32 headers, as we don't want the former included in the dependencies for speed reasons (otherwise we would slow down make).
But what about determining these are runtime. A simple stat in our include dir is fast, and should tell us whether we need to include the file in the dependencies or not.
"Dimitrie O. Paun" dpaun@rogers.com writes:
Speaking of makedep: we have this non-standard "" vs <> convention for include files, which is (1) potentially confusing, and (2) can cause problems in Winelib apps that have private headers that conflict with names of our headers.
This was changed a long time ago. The only difference now is that makedep complains if it cannot find a "" include and says nothing for a <> include, but otherwise they work just the same.
On December 12, 2002 12:51 pm, Alexandre Julliard wrote:
This was changed a long time ago. The only difference now is that makedep complains if it cannot find a "" include and says nothing for a <> include, but otherwise they work just the same.
In which case, shouldn't our includes use <> instead of ""? Using "" is not 100% correct, let alone non standard. I know, minor point, but... :)
"Dimitrie O. Paun" dpaun@rogers.com writes:
In which case, shouldn't our includes use <> instead of ""? Using "" is not 100% correct, let alone non standard. I know, minor point, but... :)
I guess they should, yes.
On December 12, 2002 02:07 pm, Alexandre Julliard wrote:
In which case, shouldn't our includes use <> instead of ""? Using "" is not 100% correct, let alone non standard. I know, minor point, but... :)
I guess they should, yes.
A perfect job for a cool Perl script :)
I haven't heard much from Patrik lately... <g>
-
Alexandre Julliard -
Dimitrie O. Paun -
Francois Gouget