On Sun Oct 27, 2019 at 05:07:39PM +0100, Jeremie Courreges-Anglas wrote:
> On Sat, Oct 19 2019, Rafael Sadowski <raf...@sizeofvoid.org> wrote:
> > On Sat Sep 28, 2019 at 01:23:06PM +0200, Jeremie Courreges-Anglas wrote:
> >>
> >> Hi,
> >>
> >> sorry for the rather late reply. I've been mulling over this for a few
> >> days.
> >>
> >> On Sat, Sep 21 2019, Rafael Sadowski <raf...@sizeofvoid.org> wrote:
> >> > Long time ago I was trying to import the clang extra tool sets without
> >> > luck. It failed because the -extra subpackage has an effect on -main.
> >> > More precisely, the cmake parts from the main package.
> >>
> >> Debian (as usual) seems to have split llvm in many subpackages. Surely
> >> they must have hit and solved a similar problem.
> >>
> >> > For this reason, I think it is best to build/install the extra tools in
> >> > the main package. I'd be in charge here, too.
> >> >
> >> > I also was trying to crate an extra packages, which includes only the
> >> > extra parts but this rise more issue in the eco system.
> >>
> >> So which problems did you hit?
> >>
> >> > I have to deal with this topic because more and more people come up to
> >> > me and ask about my last try, last otto@.
> >>
> >> > That's good because I think these tools are helpful.
> >>
> >> I can understand that, but my stance is simple: my main interest for
> >> devel/llvm is the ports tree.
> >>
> >> I'm not happy with longer devel/llvm *build* times but hey, if that's
> >> the only solution available (is it?), fine, let's build those under
> >> devel/llvm.
> >>
> >> The size increase of the -main package is a killer IMO: 605MB -> 867MB
> >> on amd64. sparc64 goes from 714MB to 1.2GB. Most of this size
> >> increase comes from the additional executables, so removing the
> >> additional .a libs (if possible) does not help.
> >>
> >> So as far as I'm concerned I don't like this approach, especially with
> >> 6.6 on the radar.
> >>
> >> --
> >> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
> >>
> >
> > Hi Jeremie, hey ports@,
> >
> > I understand your objection and I have dealt more intensively with the
> > install step in the llvm packege and ninja. I think I found THE
> > SOLUTION. I have figured out how to install ONLY the extra tools.
> > Besides, we don't have to build the whole LLVM stack.
>
> From a quick glance at the docs, this type of target is a ninja feature.
> If you apply the same trick to the build step:
>
> ALL_TARGET = tools/clang/tools/extra/all
>
> the build step moves from 3827 to 2065 targets, which should improve
> build times.
>
> > Please find attached devel/clang-tools-extra as tarball. This version
> > was successfully tested by otto@.
> >
> > I'd take care of the extra tools and keep the port in sync with
> > devel/llvm.
> >
> > OK, concerns? Thanks, RS
>
> The shared libs hack looks nasty but doesn't seem needed. Well, at
> least when restricting the build step to "tools/clang/tools/extra/all".
> I would just get rid of it.
Strange, I thought I tested it. Maybe I picked the wrong one. Works for
me and save a lot of build time (Still too much).
>
> More tweaks:
> - swig is needed for lldb (absent from your port)
> - py-recommonmark is needed for sphinx docs (disabled)
> - devel/llvm already depends on devel/gtest, no need to replicate the
> dep here
> - on !clang archs, devel/llvm already has the proper dep on eg++, no
> need to replicate here
Thanks!
>
> Here's an updated port with those points addressed.
>
> I suspect that a lot of the arch-specific Makefile goo isn't needed any
> more. The -Dpowerpc bits should probably be left out.
>
>
Works fine here but it looks like we both missed the WANTLIB line:
WANTLIB += ${COMPILER_LIBCXX} c curses edit m z
OK to move it into the tree?
