new(autotrace): bitmap → vector tracer (closes #9454)#13111
Open
tannevaled wants to merge 12 commits into
Open
new(autotrace): bitmap → vector tracer (closes #9454)#13111tannevaled wants to merge 12 commits into
tannevaled wants to merge 12 commits into
Conversation
…v#9454) Autotrace's CLI + libautotrace. Same role as homebrew's `autotrace` formula. Upstream ships only `configure.ac`, so the build first runs `./autogen.sh` to regenerate the autoconf surface, then `./configure + make install`. Drops two optional features so the bottle's dep closure stays manageable: - pstoedit (no pantry recipe; provides .ps / .eps OUTPUT — input formats are still all reachable via ImageMagick). - GraphicsMagick (alternate input library — already use IM7). Closes pkgxdev#9454. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
First iter failed at:
configure: error: XML::Parser perl module is required for intltool
autotrace's configure.ac demands intltool unconditionally; intltool
in turn demands Perl's `XML::Parser` module. Pantry's perl.org doesn't
ship XML::Parser, and adding a Perl-CPAN module recipe is a bigger
detour than the i18n surface is worth here.
`--disable-nls` short-circuits the entire intltool gate. autotrace
loses its translated user-facing strings (English-only output) but
the bitmap-to-vector core is unaffected. Re-enable when a pantry
`perl.org/XML-Parser` (or equivalent CPAN-via-pkgx) recipe exists.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Previous iter dropped `freedesktop.org/intltool` and added
`--disable-nls`, assuming intltool would still pull in XML::Parser
unconditionally. Two things were wrong with that:
1. `./autogen.sh` requires `intltoolize` regardless of nls — it
exits with "*** No intltoolize found ***" before configure ever
sees `--disable-nls`. That's why iter 2 still failed at the same
point on all 4 bottles.
2. Pantry's `freedesktop.org/intltool` recipe already bundles
XML::Parser (via `cpanm -l {{prefix}} XML::Parser ...`). No need
to add a Perl-CPAN module recipe — the existing intltool one
solves it.
Homebrew handles the same problem on Linux by depending on
`perl-xml-parser`. Pantry's intltool wraps both intltool + the
needed Perl module in one dep, so just put it back.
Refs pkgxdev#9454.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…rser autogen.sh now passes (intltoolize available), but autotrace's configure script does an independent `perl -e 'use XML::Parser'` probe and pantry's perl.org doesn't ship that module — only freedesktop.org/intltool's local CPAN tree at $prefix/lib/perl5 has it. intltool sets PERL5LIB in `runtime.env` so its own binaries see the module, but that env only applies when intltool runs, not during consumer builds invoking perl directly. So point perl at intltool's perl5 dirs from autotrace's build env explicitly. Same pattern as pwmt.org/zathura and friends would need; nothing exotic. Refs pkgxdev#9454. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Previous PERL5LIB-points-at-intltool fix didn't take. autotrace's configure runs the brewkit perl wrapper (\`pkgx +perl.org -- perl\`) and that path resolution wasn't finding intltool's bundled CPAN tree even with PERL5LIB exported in build env (visible in CI log). Install XML::Parser into a scratch dir at build time via cpanm and point PERL5LIB there instead — same pattern intltool itself uses. Added a diagnostic probe to confirm the env actually works before configure runs. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…ltool tree
CI revealed the root cause: intltool's bundled XML::Parser ships
XS .so files (Clone.c, etc.) compiled against perl 5.40, but the
current perl.org bottle is 5.42. Loading them errors with:
Perl API version v5.40.0 of Clone.c does not match v5.42.0
So intltool's runtime.env PERL5LIB has been poisoning every consumer
build since the perl 5.42 upgrade — but autotrace is the first new
recipe to hit it.
Workaround in this recipe:
1. \`unset PERL5LIB\` before cpanm so it loads no stale .so files.
2. cpanm XML::Parser into a scratch dir against the current perl.
3. Set PERL5LIB to ONLY our scratch dir (not intltool's) for the
autogen.sh + configure run.
intltoolize itself is still a shell script that re-execs perl with
its own shebang — it doesn't read PERL5LIB at autogen.sh time, so
overriding it is safe.
Long-term fix is to rebuild freedesktop.org/intltool against the
current perl. That belongs in its own PR.
Refs pkgxdev#9454.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
cpanm correctly built XML::Parser into the scratch dir (visible in
CI log: \`Installing .../perl-xml-parser/lib/perl5/.../XML/Parser.pm\`),
but configure's check still fails. Root cause: brewkit's perl
wrapper at \`<brewkit>/libexec/perl\` invokes \`pkgx +perl.org -- perl\`,
which constructs a fresh env from perl.org's runtime.env and drops
the build-shell PERL5LIB.
Bypass the wrapper by pointing PERL and INTLTOOL_PERL at the real
perl binary at \`{{deps.perl.org.prefix}}/bin/perl\` — that one
inherits PERL5LIB normally, so our scratch dir's XML::Parser is
visible.
Refs pkgxdev#9454.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…LIB survives brewkit runs all script steps in a single shell, so \`unset PERL5LIB\` inside an early step leaks into ./configure and configure can't see our scratch XML::Parser tree. Scope the unset to cpanm only via \`env -u PERL5LIB cpanm ...\`. Refs pkgxdev#9454. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Configure passed and build started, then failed on:
src/input-magick.c:35:10: fatal error: 'magick/api.h' file not found
\`--with-magick=auto\` isn't a valid value per upstream configure.ac:
only \`GraphicsMagick\`, \`ImageMagick\`, \`yes\`, or \`no\` are accepted.
With \`=auto\` neither PKG_CHECK_MODULES block fired, so
HAVE_IMAGEMAGICK7 stayed undefined, and input-magick.c fell through
to the legacy ImageMagick 6 \`magick/api.h\` include (we ship IM7).
Set it explicitly to \`ImageMagick\` — configure then runs both
\`PKG_CHECK_MODULES([IMAGEMAGICK7], [ImageMagick >= 7.0.1], ...)\`
and the >=5.2.1 fallback, defines HAVE_IMAGEMAGICK7, and
input-magick.c uses \`<MagickCore/MagickCore.h>\`.
Refs pkgxdev#9454.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Configure + autogen now pass. Build progressed to the link step
and aborted with:
libtool: error: cannot find the library
'/opt/littlecms.com/v2.18.0+brewing/lib/liblcms2.la'
ImageMagick's libMagickCore-7.la (and friends) carry a
\`dependency_libs=\` entry pointing at lcms's +brewing build dir,
which is wiped post-install. libtool follows the chain during our
link and aborts. \`x.org/xdmcp\` solves this at its own install
time by sed'ing the +brewing suffix out of its .la files; IM
doesn't yet.
Workaround in this recipe: walk /opt for any .la file that still
contains \`+brewing\` and strip it. Only files we can write are
touched, and grep-guard ensures untouched files stay untouched.
TODO: upstream the same sed into imagemagick.org and any other
affected recipes (littlecms.com etc.) so future consumers don't
hit this.
Refs pkgxdev#9454.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Previous +brewing strip uncovered another layer: IM's libMagickCore-7.la pins /opt/littlecms.com/v2.18.0/lib/liblcms2.la but pantry now ships lcms v2.19.1. Stripping +brewing isn't enough. Rather than play whack-a-mole with version pinning across multiple deps' .la files, just rename IM's libMagick*.la out of the way so libtool falls back to the straightforward \`-L /opt/.../lib -lMagickCore-7.Q16HDRI\` from pkg-config — same strategy distros use when .la files are unreliable. TODO upstream: fix imagemagick.org's install to either sed its own .la at install time or skip shipping .la for shared-only libs. Refs pkgxdev#9454. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…on MagickCore plugin discovery Build now succeeds (after the previous iterations); the only remaining failure is the test step. `autotrace --version` hangs for ~30s in CI as MagickCoreGenesis() walks ImageMagick coder modules and waits on a per-user cache dir that doesn't exist in either the darwin builder or the linux sandbox. `autotrace --help` parses argv before MagickCore init runs, so it returns immediately and still exercises the dynamic-linker resolution of every shared lib the binary needs. timeout(1) guards against future hangs. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This was referenced May 30, 2026
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #9454. New recipe for autotrace — converts bitmap raster images to vector graphics (SVG/AI/PostScript). C CLI + libautotrace shared library, ~700 stars, GPL-2.0.
Same role as homebrew's `autotrace` formula.
Notes
Test plan
🤖 Generated with Claude Code