On Fri, Sep 16, 2022 at 09:35:12AM -0400, Josh Grosse wrote:
> On Fri, Sep 16, 2022 at 08:44:09AM +0100, Stuart Henderson wrote:
> > Well done, Windows-centric software is usually a pain to get building! Sorry
> > I have found a few more things though - some easy some a bit more fiddly.
> >
> > Some of the -Wno-xxx might not be accepted by gcc, and the actual
> > warnings(->errors) produced can vary by arch, so it's simpler (and standard
> > in ports) to patch away -Werror.
>
> Thank you.
>
> > SEPARATE_BUILD is for "out of source tree" builds, with this the build dir
> > shouldn't have source files in it (the main reason for SEPARATE_BUILD is so
> > that the build dir can be cleaned without rerunning autoconf) - this port
> > has source files there so it shouldn't use SEPARATE_BUILD, and
> > s/WRKBUILD/WRKSRC/
>
> Will correct, thanks!
>
> > Installing the binary should handle stripping, the simplest way is to use
> > ${INSTALL_PROGRAM} which handles it automatically (including not stripping
> > when building with DEBUG) - I would move this to do-install rather than
> > patching upstream's Makefile.
>
> Will do!
>
> > There are some complications with the different makefiles for clang and gcc.
> > Not sure how best to handle that but it needs to build on ports-gcc arch's
> > without using clang - I don't have a suitable arch to test (sparc64 will do
> > but also need to check the build log to make sure if doesn't call clang
> > which is present there but shouldn't be used in that case). It should use
> > CC/CXX/CFLAGS/CXXFLAGS rather than hardcoding clang/clang++/-O2
>
> I only have amd64/i386 archs available, so won't be able to test this either.
>
> > The conflict isn't ideal because various other ports depend on p7zip.
> > Probably best to either replace p7zip completely (changing those other ports
> > to use 7zip) or rename the binaries in p7zip (use a 'p' prefix, again
> > changing the other ports to cope). As a result I think this port is one for
> > post-7.1.
>
> One possiblity is to only produce the `7zz` full-feature binary. There would
> be no conflict. I haven't tried to build it. So far, the only Bundle's I've
> tested have been `7za` which is in this port, and `7zr` the "restricted"
> Bundle,
> which built and ran.
>
> > (also we need some way to handle rar if it's going to replace p7zip
> > completely - e.g. build 7zz from the Alone2 dir - could either use similar
> > to the v6 flavour in ports/net/bird/1 which deals with a similar problem -
> > or could run the build in the second dir via post-build and use
> > subpackages).
>
> A quick scan of the tree shows mail/amavisd-new is currently the only port
> with
> a dependency on the unrar plugin.
>
> I will have to experiment with `7zz`, which would allow both ports to
> co-exist.
>
> Thank you, as always, for your insights and recommendations!Attached is a "v3" tarball with the above changes, producing a single `7zz` executable binary. There is no long any conflict with p7zip. I've tested this build on amd64. George may want to retest on powerpc64 to see if his patch to C/7zCrcOpt.c can be removed.
7zip.v3.tgz
Description: application/tar-gz
