I'm excluding make_opengl from this discussion because it needs to
download files so it's best to avoid having to run it.
But the various make_errors, make_vulkan and make_fir scripts could
potentially generate the relevant files at build time.
The question comes up because either the TestBot needs to detect changes
to their dependencies and rerun them when needed, or the Wine build
system needs to do it.
The latter option has some caveats:
* These scripts depend on tools like awk, perl …
[View More]and Python 3. We may
not want Wine to depend on those for its build.
* Generating files like dxerr8/errors.h at build time breaks makedep
because it fails to find the header.
Any opinions on this?
Hints on how to deal with makedep?
--
Francois Gouget <fgouget(a)codeweavers.com>
[View Less]
Signed-off-by: Francois Gouget <fgouget(a)codeweavers.com>
---
The other tools like make_opengl, make_vulkan and make_errors are all in
the directory of the related dll. So I don't see why it should be
different for make_fir.
Also it does not need any file outside the dlls/dsound directory so a cd
../.. does not seem necessary after the move.
{tools => dlls/dsound}/make_fir | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
rename {tools => dlls/dsound}/make_fir (98%)
…
[View More]diff --git a/tools/make_fir b/dlls/dsound/make_fir
similarity index 98%
rename from tools/make_fir
rename to dlls/dsound/make_fir
index 97c5583d16d..0fd26aaf7f9 100755
--- a/tools/make_fir
+++ b/dlls/dsound/make_fir
@@ -136,8 +136,7 @@ foreach my $testfreq(@testfreqs) {
# Now actually print the FIR to a C header file
-chdir ".." if -f "./make_fir";
-open FILE, ">dlls/dsound/fir.h";
+open FILE, ">", "fir.h";
select FILE;
print "/* generated by tools/make_fir; DO NOT EDIT! */\n";
--
2.20.1
[View Less]
On Thu, 5 Mar 2020, Marvin wrote:
[...]
> === debiant (build log) ===
>
> error: patch failed: dlls/d3d11/device.c:941
> error: patch failed: dlls/d3d11/state.c:1079
> error: patch failed: dlls/wined3d/device.c:3600
> error: patch failed: include/wine/wined3d.h:2037
> Task: Patch failed to apply
The TestBot mixed up this 5-parts wined3d patch series with the other
5-parts patch series for qcap / qedit.
One was a v2 and not the other so taking into account the version …
[View More]would
have avoided the issue in this case (the patch for this should go in
next monday).
But this could just as well have happened with unversioned patch series:
[PATCH 1/5] wined3d: ...
vs. [PATCH 1/5] qcap/capturegraph: ...
The subject parsing code extracts a property I have been calling the
'domain' (for lack of a better term) which is a word that's sometimes
added in the square brackets. It's usually used to indicate the Git
repository the patch should go in: [vkd3d 1/2], [tools], etc.
But it could also be used to avoid collisions between patch series:
where the TestBot identifies patch series based on the (Sender, Version,
PartCount) tuple, it could add the domain to the mix: (Sender, Domain,
Version, PartCount).
This would allow sending two patch series with the same number of parts
without causing a collision:
[wined3d 1/5] wined3d: ... + [qcap 1/5] qcap/capturegraph: ...
or [wined3d 1/5] wined3d: ... + [PATCH 1/5] qcap/capturegraph: ...
or [PATCH 1/5] wined3d: ... + [PATCH qcap 1/5] qcap/capturegraph: ...
PATCH can be thrown in to help identify patches, or omitted. It makes no
difference to the TestBot.
Not using a domain would work just as well in the absence of a
collision. And if two patch series risk colliding, adding a domain would
help avoid the collision. The only drawback is one has to anticipate and
remember to specify the domain before sending the emails.
Would taking the domain make sense? Would it be worth it?
--
Francois Gouget <fgouget(a)codeweavers.com>
[View Less]