Take a step toward complete BB domination #33125
Conversation
staticfloat
force-pushed
the
sf/complete_bb_domination
branch
from
655e822 to
4c71f14
Compare
This will not be needed anymore if we bundle `7z` with BB, as attempted in JuliaLang/julia#33125
|
Unless we actually need XML parsing for Pkg, I’d prefer not to include libexpat. Can’t it be a normal BB-provided library? |
|
The XML parsing isn't for Pkg, it's for WinRPM. I think we could get around this by making a 1.3-only release of WinRPM that uses |
staticfloat
force-pushed
the
sf/complete_bb_domination
branch
from
bfe85a7 to
6508d7d
Compare
|
With JuliaIO/LibExpat.jl#99 passing tests, I took |
staticfloat
changed the title
staticfloat
changed the title
|
This is ready to merge. |
| else | ||
| $(error no win-extras target for ARCH=$(ARCH)) | ||
| endif | ||
| @$(MAKE) -C $(BUILDROOT)/deps install-p7zip |
There was a problem hiding this comment.
this recursive calls to MAKE is race-y, so it's generally a bad idea—but also unnecessary (since the julia-deps target already does it)?
There was a problem hiding this comment.
win-extras does not depend on julia-deps, nor do we want it to. We don't want to e.g. install LLVM when you run win-extras, we only want to install p7zip; unfortunately we don't have fine-grained dependency control, so the next best thing is recursive make. install-p7zip is a simple enough operation that I think it's not that bad. julia-deps itself is just a (much larger) recursive make call anyway.
There was a problem hiding this comment.
eh, ok, it's wrong but not too bad as you say
There was a problem hiding this comment.
I think the only way this could be done "right" is if we were to include deps/Makefile from Makefile, giving us access to all those targets.
|
Unless I get another review response from Jameson, I'm going to merge this at the end of today. |
|
Talked this over in the Pkg call; we are going to implement support for |
staticfloat
force-pushed
the
sf/complete_bb_domination
branch
2 times, most recently
from
83e96e3 to
031cdae
Compare
This provides a number of benefits: * Significantly reduces the amount of work in win-extras, which I've always thought was an annoying wart in our build system. * Provides a consistent 7z executable on all platforms, which can be picked up by Pkg/BinaryProvider for consistent unzipping/untarring/ungzipping on all platforms. Note that on Windows, 7z is a repackaged binary from sourceforge and is the "full" 7z, whereas on all other platforms it is a p7zip build of the standalone 7za executable with all relevant patches applied. There are some format capability differences, but for the important things it should be fine.
staticfloat
force-pushed
the
sf/complete_bb_domination
branch
from
031cdae to
bbf7310
Compare
|
Updated PR: we now provide build recipes for I have tested that this builds p7zip and libz without BB on MacOS x86_64, Linux x86_64 and AArch64, so I'm satisfied that this is working reasonably well. Note that I did not take the time to tune compiler flags for |
This provides a number of benefits: * Significantly reduces the amount of work in win-extras, which I've always thought was an annoying wart in our build system. * Provides a consistent 7z executable on all platforms, which can be picked up by Pkg/BinaryProvider for consistent unzipping/untarring/ungzipping on all platforms. Note that on Windows, 7z is a repackaged binary from sourceforge and is the "full" 7z, whereas on all other platforms it is a p7zip build of the standalone 7za executable with all relevant patches applied. There are some format capability differences, but for the important things it should be fine. (cherry picked from commit b6ddd87)
What's the recommended practise for using the |
|
Try looking in joinpath(Sys.BINDIR, “..”, “libexec”)
…On Tue, Sep 24, 2019 at 06:47 Curtis Vogt ***@***.***> wrote:
Provides a consistent 7z executable on all platforms
What's the recommended practise for using the 7z executable? On the
current nightly build of Julia (1.4.0-DEV.194) I can't seem to locate the
executable.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#33125?email_source=notifications&email_token=AAA762BR6XYEVBUQ64LU7PLQLIK7PA5CNFSM4ISRXIH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7ONFXY#issuecomment-534565599>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAA762DKFYOWHFYZ4NU6YGTQLIK7PANCNFSM4ISRXIHQ>
.
|
|
On the Julia nightly for Windows 64-bit the |
|
7z fails to build on FreeBSD with |
|
Related: #33592 |
Julia 1.3 moved the location of 7zip: JuliaLang/julia#33125
This provides a number of benefits: * Significantly reduces the amount of work in win-extras, which I've always thought was an annoying wart in our build system. * Provides a consistent 7z executable on all platforms, which can be picked up by Pkg/BinaryProvider for consistent unzipping/untarring/ungzipping on all platforms. Note that on Windows, 7z is a repackaged binary from sourceforge and is the "full" 7z, whereas on all other platforms it is a p7zip build of the standalone 7za executable with all relevant patches applied. There are some format capability differences, but for the important things it should be fine. (cherry picked from commit 8df4902)
This provides a number of benefits: * Significantly reduces the amount of work in win-extras, which I've always thought was an annoying wart in our build system. * Provides a consistent 7z executable on all platforms, which can be picked up by Pkg/BinaryProvider for consistent unzipping/untarring/ungzipping on all platforms. Note that on Windows, 7z is a repackaged binary from sourceforge and is the "full" 7z, whereas on all other platforms it is a p7zip build of the standalone 7za executable with all relevant patches applied. There are some format capability differences, but for the important things it should be fine.
This provides a number of benefits: * Significantly reduces the amount of work in win-extras, which I've always thought was an annoying wart in our build system. * Provides a consistent 7z executable on all platforms, which can be picked up by Pkg/BinaryProvider for consistent unzipping/untarring/ungzipping on all platforms. Note that on Windows, 7z is a repackaged binary from sourceforge and is the "full" 7z, whereas on all other platforms it is a p7zip build of the standalone 7za executable with all relevant patches applied. There are some format capability differences, but for the important things it should be fine. (cherry picked from commit 16225e6)
This provides a number of benefits: * Significantly reduces the amount of work in win-extras, which I've always thought was an annoying wart in our build system. * Provides a consistent 7z executable on all platforms, which can be picked up by Pkg/BinaryProvider for consistent unzipping/untarring/ungzipping on all platforms. Note that on Windows, 7z is a repackaged binary from sourceforge and is the "full" 7z, whereas on all other platforms it is a p7zip build of the standalone 7za executable with all relevant patches applied. There are some format capability differences, but for the important things it should be fine. (cherry picked from commit 358c406)
This provides a number of benefits: * Significantly reduces the amount of work in win-extras, which I've always thought was an annoying wart in our build system. * Provides a consistent 7z executable on all platforms, which can be picked up by Pkg/BinaryProvider for consistent unzipping/untarring/ungzipping on all platforms. Note that on Windows, 7z is a repackaged binary from sourceforge and is the "full" 7z, whereas on all other platforms it is a p7zip build of the standalone 7za executable with all relevant patches applied. There are some format capability differences, but for the important things it should be fine.
Provide libexpat, libz and p7zip (true 7z for Windows) on all platforms. This provides a number of benefits:
Significantly reduces the amount of work in
win-extras, which I've always thought was an annoying wart in our build system.Provides a consistent
7zexecutable on all platforms, which can be picked up byPkg/BinaryProviderfor consistent unzipping/untarring/ungzipping on all platforms. Note that on Windows,7zis a repackaged binary from sourceforge and is the "full"7z, whereas on all other platforms it is ap7zipbuild of the standalone7zaexecutable with all relevant patches applied. There are some format capability differences, but for the important things it should be fine.We kind of half-heartedly guaranteed to packages like WinRPM (through
LibExpat.jl) thatlibexpatwould always be available. This is inconsistently true across platforms, so let's fix that by just shipping it everywhere just like any other dependency.