Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use a common build script for both CURL and LibCURL #4472

Merged
merged 3 commits into from
Feb 24, 2022

Conversation

DilumAluthge
Copy link
Member

@DilumAluthge DilumAluthge commented Feb 21, 2022

Fixes #2720
Closes #4153

@DilumAluthge
Copy link
Member Author

cc: @ericphanson @giordano

L/LibCURL/common.jl Outdated Show resolved Hide resolved
L/LibCURL/common.jl Outdated Show resolved Hide resolved
L/LibCURL/common.jl Outdated Show resolved Hide resolved
L/LibCURL/common.jl Outdated Show resolved Hide resolved
Comment on lines 1 to 3
include("../common.jl")

build_libcurl(ARGS, "LibCURL")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to rebuild libcurl, nothing changed. This file should be removed from this PR and added in a follow-up PR with [skip ci].

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it cool if I leave the file in until the PR is ready to merge, just to make sure that CI passes (and that I don't have any bugs for the libcurl code path)? And then, once the PR is ready to merge, I'll remove the file from this PR, and then you can merge immediately afterwards?

L/LibCURL/common.jl Outdated Show resolved Hide resolved
@giordano
Copy link
Member

giordano commented Feb 21, 2022

One thing which you may want to consider is to do a static build of curl which doesn't depend on libcurl at all, which is annoying because that's tied to a julia version.

Edit: on a second thought, you'd need also static libraries of libmedtls and libssh2, which we don't have, so that's not going to fully disentangle curl from julia's libraries anyway.

Co-authored-by: Eric Hanson <5846501+ericphanson@users.noreply.github.com>

Co-authored-by: Mosè Giordano <giordano@users.noreply.github.com>
@DilumAluthge
Copy link
Member Author

DilumAluthge commented Feb 24, 2022

@giordano @staticfloat Apart from deleting the L/LibCURL/LibCURL/build_tarballs.jl file, is there anything else that needs to be done for this PR?

@giordano
Copy link
Member

This still creates libcurl in CURL_jll and curl in LibCURL_jll. Isn't there a way to avoid this duplication? This also kind of defeats the point of having CURL_jll depending on LibCURL_jll.

@DilumAluthge
Copy link
Member Author

I have no idea. @staticfloat?

@giordano
Copy link
Member

Or, put in another way: what do Linux distributions do? They also split libcurl and curl into different packages.

@staticfloat
Copy link
Member

Just delete libcurl from the CURL_jll package. Once we have the ability to split a single build out into multiple JLLs we can avoid rebuilding the products twice.

Comment on lines +65 to +73
if [[ "${THIS_IS_CURL}" == true ]]; then
# Manually install only `curl`
install -Dm 755 "src/.libs/curl${exeext}" "${bindir}/curl${exeext}"
else
# Install everything...
make install
# ...but remove `curl`
rm "${bindir}/curl${exeext}"
fi
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I followed what I did in

if [[ "${ICU}" == true ]]; then
# Manually install only ICU-related files
cp src/libharfbuzz-icu*${dlext}* ${libdir}/.
cp meson-private/harfbuzz-icu.pc ${prefix}/lib/pkgconfig/.
cp ../src/hb-icu.h ${includedir}/harfbuzz/.
else
ninja install
fi
which is what I've been telling to look at

@giordano giordano merged commit 7cfae68 into master Feb 24, 2022
@giordano giordano deleted the dpa/curl-executables branch February 24, 2022 23:41
end

# Build the tarballs, and possibly a `build.jl` as well.
build_tarballs(ARGS, name, version, sources, script, platforms, products, dependencies; julia_compat="1.8")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 1.8 only?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@ericphanson ericphanson Feb 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh… I guess that’s why we’d want a fully static thing like you mentioned. Annoying.

Still, thanks for your help with this!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@giordano @staticfloat What if we:

  1. Don't make CURL_jll depend on LibCURL_jll
  2. When building CURL_jll, don't delete libcurl. So then CURL_jll will supply both libcurl and curl.

Would that allow us to use the same version of CURL_jll on multiple versions of Julia?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, so we'd need static libraries for all of the dependencies.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this just means that we need to remember to make a new release of CURL_jll every time there's a new minor release of Julia, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, just always build CURL_jll together with (well, right after) a new LibCURL_jll.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, just always build CURL_jll together with (well, right after) a new LibCURL_jll.

It would be nice if we could automate that process.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JuliaPackaging/BinaryBuilder.jl#778. This is what #4472 (comment) and

# Bash recipe for building across all platforms
# Side note: this is a great use-case for
# https://github.com/JuliaPackaging/BinaryBuilder.jl/issues/778
were referring to.

@DilumAluthge
Copy link
Member Author

@giordano @staticfloat @ericphanson Thanks so much for your help with this!

@giordano
Copy link
Member

For the record, showing this is working:

julia> using CURL_jll

julia> run(`$(curl()) --version`);
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 mbedTLS/2.28.0 zlib/1.2.11 libssh2/1.10.0 nghttp2/1.41.0
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS HSTS HTTP2 IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets

giordano added a commit to giordano/BinaryBuilder.jl that referenced this pull request Feb 28, 2022
Yggdrasil pull request JuliaPackaging/Yggdrasil#4472
deleted the file `L/LibCURL/build_tarballs.jl`, which made the test checking
that the file exists fail.  Arguably, we should make the check more robust, but
it'd be considerably more work for relatively little gain (vast majority of
packages do follow the predictable naming scheme).
giordano added a commit to giordano/BinaryBuilder.jl that referenced this pull request Feb 28, 2022
Yggdrasil pull request JuliaPackaging/Yggdrasil#4472
deleted the file `L/LibCURL/build_tarballs.jl`, which made the test checking
that the file exists fail.  Arguably, we should make the check more robust, but
it'd be considerably more work for relatively little gain (vast majority of
packages do follow the predictable naming scheme).
giordano added a commit to JuliaPackaging/BinaryBuilder.jl that referenced this pull request Feb 28, 2022
Yggdrasil pull request JuliaPackaging/Yggdrasil#4472
deleted the file `L/LibCURL/build_tarballs.jl`, which made the test checking
that the file exists fail.  Arguably, we should make the check more robust, but
it'd be considerably more work for relatively little gain (vast majority of
packages do follow the predictable naming scheme).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Builder Request: a Curl_jll.jl package that includes the curl binary executable
4 participants