RE: Houston, we have a problem...
> 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 :) Sure. Will try to look at in the next few days. > I haven't heard much from Patrik lately... You will here more from me soon. I'm going to have a long vacation around christmas where I will have much more time to work with Wine. Of course family and friends usually takes up more time than usual around christmas as well...
Re: Houston, we have a problem...
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... -- Dimi.
Re: Houston, we have a problem...
"Dimitrie O. Paun" <[EMAIL PROTECTED]> 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Houston, we have a problem...
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... :) -- Dimi.
Re: Houston, we have a problem...
"Dimitrie O. Paun" <[EMAIL PROTECTED]> 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Houston, we have a problem...
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. -- Dimi.
Re: Houston, we have a problem...
Francois Gouget <[EMAIL PROTECTED]> 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Houston, we have a problem...
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 . 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 [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
