On 2023/05/02 00:51, Klemens Nanni wrote:
> On Tue, May 02, 2023 at 12:48:52AM +0200, Volker Schlecht wrote:
> > Attached are ports for
> >
> > devel/gn
> > https://gn.googlesource.com/gn/
> > Based on a snapshot from 20230419
> > MASTER_SITE is a personal mirror, since googlesource doesn't provide
> > stable archives.
>
> Can you add a comment for that?
+1
> The COMPILER line wants a "C++17" comment; passing -v to build shows compiler
No need IMO. It's C++ so it needs a COMPILER line anyway; it doesn't
particularly matter which standard and those things have a habit of
getting out of sync later.
> output which we want to see... -O3 usage needs to patched out.
+1
> I set USE_CCACHE=Yes, but it is not picked up; cmake ports default to ninja,
> there it works.
This is because MAKE_ENV is not passed through.
> You patch out git usage, is that for gn's build itself and/or consumers?
> Please add a comment to the patch so things like these are clear to porters.
>
> Have you tried splitting sources and build artifacts (SEPARATE_BUILD=Yes,
> then probably -C/cd here and there with WRKSRC and WRKBUILD)?
It's already split into out/, a fully separate WRKBUILD doesn't work
as-is (some things require the build dir to be a subdirectory of the
source dir, not one alongside, plus there are other problems), I don't
think we should add patches to support that.
> mkdir should be INSTALL_DATA_DIR.
yep (though I'm not sure it really matters any more..)
others:
Is there any reason not to have a RUN_DEPENDS on ninja?
Setting PKGNAME=0.0.$DATE would avoid most reasons for needing EPOCH if
this ever did get a versioned release
I'd set DPB_PROPERTIES=parallel.
> Did you look into failing tests?
> [40/688] FormatTest.001
> ...
> [121/688] FormatTest.084
> for example all fail; could be one (simple) fix this class.
Start the tests from ${WRKSRC}/out and FormatTest.001 succeeds but
subsequent fail.
As is common with some other recent software it doesn't cope properly
with OS that don't allow finding the path of the current executable.
In this case it tries to use the result (i.e. "") but it expects it to
be an absolute path with trailing /, and chdirs to that path plus ..
(i.e. WRKSRC/out/..) so that it can find the data files. So chdir("..").
The first one succeeds but then it walks the path up to / for subsequent
files with obvious results.
Probably the best you can do is add another case to GetExePath that
uses the full path from argv[0] if present and otherwise falls back to
/usr/local/bin/gn, and when running tests call it with the full path.
> >
> > needed by
> >
> > lang/deno
>
> Will look at this another time.
>
> > https://deno.com
> > Includes a gazillion patches for v8, taken from www/chromium
> > Includes half a gazillion patches adapted from the FreeBSD port
> > Caveats:
> > * stub function to retrieve the resident set size is stubbed to always
> > return 0
> > * misses an implementation of Deno.systemMemoryInfo()
> > --> Deno.systemMemoryInfo() and Deno.memoryUsage() don't crash, but
> > don't return useful values either.
> >
> > amd64: both tested, both seem to work reasonably well.
> >
> > arm64: devel/gn tested, lang/deno still building because RaspberryPi ...
>
>
>
