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

New package: mercury-22.01_1, mercury-libs-22.01_1, mercury-tools-22.01_1 #36905

Merged
merged 1 commit into from Aug 2, 2022

Conversation

AlaskanEmily
Copy link
Contributor

@AlaskanEmily AlaskanEmily commented Apr 28, 2022

Testing the changes

  • I tested the changes in this PR: YES

New package

Local build testing

  • I built this PR locally for my native architecture, (x86_64-glibc)
  • I built this PR locally for these architectures (if supported. mark crossbuilds):
    • x86_64-musl
    • i686-glibc

I have marked the parallel toolchain options disabled for musl, as in the last those have had issues and I have not tested that configuration enough to be sure it works properly.

@AlaskanEmily
Copy link
Contributor Author

Ah, I know how to fix the i686 failure, that's what happens when you try to use asm_fast as the base LLDS grade on a platform that doesn't support it.

_LLDS_GRADE=none ;;
esac

_LIBGRADES="hlc.gc,hlc.gc.ssdebug,hlc.gc.memprof,${_LLDS_GRADE}.gc,${_LLDS_GRADE}.gc.stseg,${_LLDS_GRADE}.gc.stseg.decldebug,${_LLDS_GRADE}.gc.stseg.profdeep"
Copy link
Contributor

Choose a reason for hiding this comment

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

I would remove hlc.gc.ssdebug.

Consider adding hlc.gc.prof and ${_LLDS_GRADE}.gc.debug.stseg.

I suggest listing the grade components in canonical order.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would remove hlc.gc.ssdebug.

I use ssdebug fairly often, it's extremely useful for debugging issues that only happen in HLC, I would prefer to keep it.

Consider adding hlc.gc.prof and ${_LLDS_GRADE}.gc.debug.stseg.

Isn't decldebug a strict superset of debug?

I suggest listing the grade components in canonical order.

Is there an actual documented canonical order?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, keep ssdebug then.

decldebug is a superset of debug but produces bigger code which is slower to compile. However, a quick check on a project shows that it's only about 6% slower to compile, less than I thought, and the runtime difference is pretty acceptable, too. So it should be fine to skip the .debug grade.

The canonical order is implemented by the canonical_grade script and mmc --output-grade-string.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, I reordered the grades based on its output.

srcpkgs/mercury/template Show resolved Hide resolved
vman usr/share/man/man1/mdb.1
vman usr/share/man/man1/mprof.1
vman usr/share/man/man1/mprof_merge_runs.1
vman usr/share/man/man1/mtags.1
Copy link
Contributor

Choose a reason for hiding this comment

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

mdb is a trivial shell script. I think it should be in the main package.

mtags depends on perl. It's pretty small and more useful than the other tools in this list. Consider moving it to the main package.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Moved

@AlaskanEmily
Copy link
Contributor Author

@wangp Is there anything else I need to change before this can be added?

@wangp
Copy link
Contributor

wangp commented May 16, 2022

It looks okay to me. mtags requires perl at runtime, so you might need a dependency on perl.

}

mercury-libs_package() {
license="custom:LGPL-2.0-only-linking-exception"
Copy link
Member

Choose a reason for hiding this comment

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

this does not affect the metadata on the subpkg, i think (based on this)

srcpkgs/mercury/template Show resolved Hide resolved
vman usr/share/man/man1/mmake.1
vman usr/share/man/man1/mmc.1
vman usr/share/man/man1/mtags.1
vlicense COPYING
Copy link
Member

Choose a reason for hiding this comment

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

should not be needed if this is GPL

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If this can't be set on the subpackage, should I set the entire license to be GPL, custom:LGPL-2.0-only-linking-exception then?

For reference, the runtime libraries are LGPL with a static linking exception, and the compiler toolchain itself is GPL.

Copy link
Member

Choose a reason for hiding this comment

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

yeah GPL-2.0-only, custom:LGPL-2.0-only-linking-exception and only install the custom one in the packages

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

srcpkgs/mercury/template Show resolved Hide resolved
distfiles="http://dl.mercurylang.org/release/mercury-srcdist-${version}.tar.xz"
checksum=4ab0734aaa66808c91ffe7f54c7d818bdc4f0247aa255932e1e3d50610db4150
nocross="Mercury cannot be cross-compiled to different architectures"
noverifyrdeps=yes
Copy link
Member

Choose a reason for hiding this comment

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

what's the rationale for these settings?

@leahneukirchen
Copy link
Member

Also please rebase for CI.

homepage="https://mercurylang.org/"
distfiles="http://dl.mercurylang.org/release/mercury-srcdist-${version}.tar.xz"
checksum=4ab0734aaa66808c91ffe7f54c7d818bdc4f0247aa255932e1e3d50610db4150
nocross="Mercury cannot be cross-compiled to different architectures"
Copy link
Member

Choose a reason for hiding this comment

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

We usually set $nocross to yes or set it to a reason why it can't be cross compiled. This sounds to me like this can't be cross compiled because it can't be cross compiled.

maintainer="Emily McDonough <emily@alaskanemily.net>"
license="GPL-2.0-only"
homepage="https://mercurylang.org/"
distfiles="http://dl.mercurylang.org/release/mercury-srcdist-${version}.tar.xz"
Copy link
Member

Choose a reason for hiding this comment

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

https?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Comment on lines 61 to 62
vmkdir /usr/lib/mercury/lib
vmkdir /usr/lib/mercury/conf
Copy link
Member

Choose a reason for hiding this comment

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

I think these should not have a leading slash

Comment on lines 85 to 92
vcopy usr/lib/mercury/conf/Mercury.config /usr/lib/mercury/conf/Mercury.config
vcopy usr/lib/mercury/conf/mercury_conf.h /usr/lib/mercury/conf/mercury_conf.h
vcopy usr/lib/mercury/ints /usr/lib/mercury/ints
vcopy usr/lib/mercury/inc /usr/lib/mercury/inc
vcopy usr/lib/mercury/ints /usr/lib/mercury/ints
vcopy usr/lib/mercury/mdb /usr/lib/mercury/mdb
vcopy usr/lib/mercury/mmake /usr/lib/mercury/mmake
vcopy usr/lib/mercury/lib/libgc*.a /usr/lib/mercury/lib
Copy link
Member

Choose a reason for hiding this comment

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

also should not have leading slashes, i think

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

srcpkgs/mercury/template Show resolved Hide resolved
noverifyrdeps=yes
noshlibprovides=yes
pkg_install() {
vmkdir /usr/lib/mercury/lib
Copy link
Member

Choose a reason for hiding this comment

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

also no leading slash

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

noshlibprovides=yes
pkg_install() {
vmkdir /usr/lib/mercury/lib
vcopy usr/lib/mercury/lib/libgc*.so /usr/lib/mercury/lib
Copy link
Member

Choose a reason for hiding this comment

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

this should probably be vmove? vcopy means that the file will exist in both mercury and mercury-libs, which would make them conflict.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The mercury-libs version only copies shared libraries, and the mercury version only copies static libraries, so it should work properly I think? If there was a conflict, I would also see this when trying to install or remove the resulting packages, right?

Comment on lines 126 to 127
vmkdir /usr/lib/mercury/lib/$GRADE
vcopy usr/lib/mercury/lib/$GRADE/lib*.so /usr/lib/mercury/lib/$GRADE
Copy link
Member

Choose a reason for hiding this comment

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

same thing here (leading slash and vmove)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed leading slash. Is my comment above applicable? Or should this still change to vmove?

srcpkgs/mercury/template Show resolved Hide resolved
@AlaskanEmily AlaskanEmily force-pushed the master branch 4 times, most recently from da570c8 to 7d6e5b0 Compare July 4, 2022 00:42
@leahneukirchen
Copy link
Member

I tried to remove the noverifyrdeps, but it fails not finding libpar_gc.so and I can't actually see it. Any ideas?

@AlaskanEmily
Copy link
Contributor Author

I tried to remove the noverifyrdeps, but it fails not finding libpar_gc.so and I can't actually see it. Any ideas?

It should be copied by the usr/lib/mercury/lib/libgc*.so vcopy.

I had a bunch of issues with the verifyrdeps and verifydeps for libgc and its derivatives, but I didn't think it was important to solve in particular because Mercury has a patched version of libgc which is not compatible with regular Boehm GC (also why it's installed to a "mercury" directory instead of to /usr/lib).

@AlaskanEmily
Copy link
Contributor Author

AlaskanEmily commented Jul 23, 2022

I tried to remove the noverifyrdeps, but it fails not finding libpar_gc.so and I can't actually see it. Any ideas?

It should be copied by the usr/lib/mercury/lib/libgc*.so vcopy.

I had a bunch of issues with the verifyrdeps and verifydeps for libgc and its derivatives, but I didn't think it was important to solve in particular because Mercury has a patched version of libgc which is not compatible with regular Boehm GC (also why it's installed to a "mercury" directory instead of to /usr/lib).

Having reread this, I see the problem now :)

@AlaskanEmily AlaskanEmily force-pushed the master branch 2 times, most recently from ad69cd0 to 31d3286 Compare July 23, 2022 03:38
@leahneukirchen
Copy link
Member

Ok, let's finish this up. Remove noshlibprovides and shlib_requires from the main package, and noverifyrdeps and noshlibprovides from the subpackages. mercury will depend on mercury-libs which depends on libc so that's fine.

LGTM else.

@leahneukirchen
Copy link
Member

Thanks a lot for holding up with us. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new-package This PR adds a new package
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants