I trimmed the libmicrohttpd sources and defines down to the minimum needed to build and run. This builds and runs on Linux and Android for me.
Request.h was missing an include for SkTypes.h, which supplies the default for SK_GPU_SUPPORTED if not otherwise defined.
To build on Android, exit() -> _exit().
build.py was unused.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2367513002
NOTREECHECKS=true
Review-Url: https://codereview.chromium.org/2367513002
I was just lazy disabling this before. It turns out to not be difficult.
This gets us slightly better testing out of the NoGPU bot, as we now know
not only that Skia compiles, but also that DM and nanobench can link (and
thus that Skia's got enough compiled in it to be a coherent library).
skpbench requires GPU support.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2356283002
Review-Url: https://codereview.chromium.org/2356283002
is_skia_standalone will be defined and set to true iff we're using our
standalone BUILDCONFIG.gn. Any other build (Fuchsia, Chrome, Pdfium)
will have their own BUILDCONFIG.gn, which presumably does not define
is_skia_standalone.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2357963002
Review-Url: https://codereview.chromium.org/2357963002
Chromium needs to be able to set up their build such that the globals
continue existing but the SkFontMgr::Factory can be defined separately.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2346333002
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac-Clang-x86_64-Release-CMake-Trybot
Review-Url: https://codereview.chromium.org/2346333002
skpbench is a benchmarking suite for skps that aims to generate 100%
repeatable results. The initial commit consists of three parts:
skpbench
A minimalist program whose sole purpose is to open an skp file,
benchmark it on a single config, and exit. No tiling, looping, or
other fanciness is used; it just draws the skp whole into a size-
matched render target and syncs the GPU after each draw.
Limiting the entire process to a single config/skp pair helps to keep
the results repeatable.
skpbench.py
A wrapper to execute the skpbench binary with various configs and skps.
It also monitors the output in order to filter out and re-run results
with an unacceptable stddev.
In the future this script will lock down and monitor clocks and
temperatures.
parseskpbench.py
A utility for parsing skpbench output into a spreadsheet.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2341823002
Review-Url: https://codereview.chromium.org/2341823002
Android API >= 24 implies Vulkan support, so we can have a more useful default here than 'false'. If for some reason you wanted to turn it off, you can still override skia_use_vulkan.
The defined(ndk_api) guards other users of our GN files (Fuchsia) who may not have an ndk_api argument defined in their BUILDCONFIG.gn.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2347843003
Review-Url: https://codereview.chromium.org/2347843003
... and use it to control debug symbols and SK_ALLOW_STATIC_GLOBAL_INITIALIZERS.
This will most directly have the effect of disabling GLProgramsTest and a bunch
of similar failing Vk tests on Android.
Hopefully this makes the N7 trybot go green, keeping the N5 trybot green. Just running the N10 for fun.
(is_official_build is how Chrome terms this sort of ReleaseForReal build.)
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2340723003
Review-Url: https://codereview.chromium.org/2340723003
Android's the easiest place to start supporting Vulkan, so it's up first.
ndk_api becomes user-specifiable so that the Vulkan bots can kick it up
to 24, the first release supporting Vulkan. The defaults remain the same:
18 for 32-bit and 21 for 64-bit, the first release supporting 64-bit.
To test this, I set ndk_api=24 and skia_use_vulkan=true in GN, then
$ ninja -C out dm; and droid out/dm --config vk --src gm
Seems to work! Bot scripts to follow.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2336343002
Review-Url: https://codereview.chromium.org/2336343002
Kind of a big change, to connect several new bits into something useful:
* ID tracking & lookup
* new asPaint() node virtual to support shader (and in the future filter) based paint servers
* <defs>, <linearGradient> and <stop> element support
* 'href', 'offset', 'stop-color', 'stop-opacity' attribute support
* IRI/FuncIRI and rgb(...) parsing
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2327233003
Review-Url: https://codereview.chromium.org/2327233003
What do you think of this? It's basically what you wrote, factored differently.
Flipping on skia_use_freetype will enable the SkFontHost_Freetype*.cpp files
via the :typeface_freetype target.
Then we just pull out the SkFontMgr Fuchsia wants to use into its own little
:fontmgr_fuchsia target. No major difference here, except the availability
of freetype headers, etc, is a bit more tightly scoped to just those that
need them.
We (obviously?) don't have Fuchsia builders, so I've got to rely on you for sanity testing this.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2333913002
Review-Url: https://codereview.chromium.org/2333913002
The SK_GAMMA_ defines change text rendering on Android.
This is how they're set in GYP for Android... everyone else is default (sRGB).
Linking AndroidSkDebugToStdOut.o causes SkDebugf to go to both logcat and
stdout on Android. Without it, it only goes to logcat. The file has no effect
on non-Android platforms.
BUG=skia:
Review-Url: https://codereview.chromium.org/2323353002
This makes skia_use_fontconfig=false build on Linux. Instead of using
fontconfig it looks in /usr/share/fonts.
That alone is a nice feature to have, but it's mostly relevant for MSAN,
where we can't link against any uninstrumented system libraries.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2318133003
Review-Url: https://codereview.chromium.org/2318133003
This file will be imported by Chrome to access the sources lists.
Once Chrome is updated to use this file, changes to the skia .gypi layout can
be done entirely within the skia repository as long as the resulting lists
produced by the new .gni file have the same name.
Marks skia_for_chromium_defines as obsolete and moves the definition into the new .gni file. We can remove the .gypi file when Chrome is updated.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2302803005
Review-Url: https://codereview.chromium.org/2302803005
This way you don't need to set LSAN_SUPPRESSIONS in your environment...
sort of foolproof this way.
I _think_ the strdup() business from skia:2916 is actually rooted in
libfontconfig, so one suppression should cover both old ones.
I'll leave the file empty until I clean up mention of it in bot recipes.
BUG=skia:2916
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2295153003
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot
Review-Url: https://codereview.chromium.org/2295153003
Also make sources_when_disabled and public_defines optional arguments.
These are the two mechanisms code uses to turn itself off...
probably at most one is ever used per optional.
Update fiddle to not crash when there's no PDF backend.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2292343003
Review-Url: https://codereview.chromium.org/2292343003
This fixes this warning-as-error, so we don't have to stifle it any more:
error: 'register' storage class specifier is deprecated and incompatible with C++1z [-Werror,-Wdeprecated-register]
Tested by building for mipsel via GN.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2289293002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2289293002
Once you have downloaded an android NDK, you can set the ndk GN arg to use it.
E.g. my gn.args looks like:
is_debug = false
ndk = "/opt/android-ndk"
This should be enough to get you going for an arm64 build. You ought to be able to tweak that to other architectures by changing target_cpu to "arm", "x86", "x86-64", etc. That won't quite work until I follow this up a bit, but the skeleton is there.
This is enough to get me compiled, linked, and running to completion on my N5x.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2275983004
Review-Url: https://codereview.chromium.org/2275983004
No more:
#include SK_SFNTLY_SUBSETTER
#include ZLIB_INCLUDE
Also, rename SK_SFNTLY_SUBSETTER to SK_PDF_USE_SFNTLY
to follow my pattern of prefixing SkPDF-specific defines
with 'SK_PDF_'.
The ZLIB_INCLUDE define is no longer is used by anyone.
TODO: rename Sfntly to something pronounceable.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2273343002
Review-Url: https://codereview.chromium.org/2273343002
- Use options' template pattern for opts too.
- Simplify opt's and options' configs... they should all be the same.
- When building a static-library component in our GN environment (i.e. libskia.a),
make it a complete static lib, fully containing its transitive deps.
- It has not proved useful to override ar.
TBR=jcgregorio@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2278673002
Review-Url: https://codereview.chromium.org/2278673002
Our tools use third-party libraries pretty freely, some of which may not
be available in other GN environments (e.g. Fuchsia). Most can also not
function when Skia is built as a shared library.
fiddle stands alone as the exception to both those points: it depends on
only Skia, and works fine with both a shared or static library.
So guard everything but fiddle with this flag skia_enable_tools, disabled
when we're building for Fuchsia or when we're build a shared library.
This CL has a couple of little tweaks to Fiddle to keep it working:
- divorce it from :tool_utils, instead just building SkForceLinking.cpp itself;
- fix up a buggy rebase_path() that was accidentally working when we depended
on :tool_utils;
- drop test_only: it now only requires production-code dependencies.
The SkImageEncoder Create* methods need to be SK_API if we want SkForceLinking
to work across .so's. Without this, SkForceLinking needs to be part of Skia; it
can't be part of the application using Skia.
The rest is mostly just a re-indent under if (skia_enable_tools),
courtesy of gn format.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2273823003
No public API changes.
TBR=reed@google.com
Review-Url: https://codereview.chromium.org/2273823003
This will be handy for folks who don't have libwebp, like Fuchsia.
I convinced myself that this is done right by:
- building in all three modes (default and explicitly set both ways);
- looking at verbose Ninja logs to see the presence/lack of SK_HAS_WEBP_LIBRARY;
- running dm -m Codec, which passes with libwebp and segfault without it.
If this is viable, I intend to make all third-party dependencies optional
and follow this pattern. :skia should link and degrade gracefully without
any of //third_party. It's okay for tools to have hard third-party
dependencies; we just need them to get past the `gn gen` stage without them.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2270693004
Review-Url: https://codereview.chromium.org/2270693004
We might as well match the folks who are using our GN files now.
We've got plenty of strategies in our pocket for when we try to move Chrome
onto our GN files (and who knows, there may be even a new better way by then):
* Same sort of rename in Chrome's third_party
* Aliased targets via //build/secondary in Chrome.
* Indirection via build_overrides
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2265503002
Review-Url: https://codereview.chromium.org/2265503002
About 9x faster than Murmur3 for long inputs.
Most of this is a mechanical change from SkChecksum::Murmur3(...) to SkOpts::hash(...).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2208903002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot;master.client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac-Clang-x86_64-Release-CMake-Trybot
Review-Url: https://codereview.chromium.org/2208903002
If you want to try this out, the DOCS_PREVIEW link is a quickstart.
Are the GrGLCreateNativeInteface_* meant to be part of Skia-the-library
or just used by testing tools? I've got it written here as tool-only,
but we could easily move it to libskia if it's a thing we want to ship.
I'm honestly not sure I understand how this linked before without a definition
of GrGLCreateNativeInterface(). Or are there two, one real and one no-op
default with some sort of weak linking setup? dlopen()?
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2201233003
DOCS_PREVIEW= https://skia.org/user/quick/gn?cl=2201233003
Review-Url: https://codereview.chromium.org/2201233003
exec_script runs every time gn does, which is explicitly on every one of our
bot runs. That should be enough to obviate the .git/logs/HEAD hack.
Easiest way to do this was to swap around find.py's argument order to allow
multiple search directories. This is the root of all the .gyp changes.
This moves the blacklist into BUILD.gn, which I think is nice.
It expands it a little as we're now searching recursively, into include/gpu/vk
which we can't include safely without the Vulkan SDK.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2205903004
Review-Url: https://codereview.chromium.org/2205903004
These files are now so badly misnamed that it is causing problems.
The original files are kept as shells until Chromium and PDFium can
be updated. After Chromium and PDFium builds are updated, the old
files will be removed and the cmake and bzl builds will be updated.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2199973002
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac-Clang-x86_64-Release-CMake-Trybot
Review-Url: https://codereview.chromium.org/2199973002
SkForceLinking wasn't force-linking the WEBP encoder, or any encoder.
(The others must be explicitly used.)
This should help the GN Debug Perf bots progress past
Running Encode_color_wheel.jpg_WEBP nonrendering
../../../bench/EncoderBench.cpp:58: fatal error: "assert(data)"
On my laptop, a debug nanobench run now finishes.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2196243002
Review-Url: https://codereview.chromium.org/2196243002
Add nanobench, and while we're at it monobench to show off how cool
source_sets are... the bench files are only built once then linked
into both binaries. With GYP we build them twice. :/ Same deal
for GMs between nanobench and DM... build once, link twice.
nanobench uses SkImageEncoder to encode its .pngs, which requires
we link in the image encoders, which requires we get them all in.
That's the bulk of this.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2193513002
Review-Url: https://codereview.chromium.org/2193513002
These flags hide symbols that are not marked with SK_API when linked into a
shared library. There's nominally no effect on static linking, but I'm
pretty sure the Mac linker takes some advantage of this too to run faster.
This makes component-build DM no longer link: it uses many non SK_API APIs.
Fiddle in contrast is just fine with our public APIs, so no need to restrict that.
It'll be fun finding out which of our other tools go which ways.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2180383003
Review-Url: https://codereview.chromium.org/2180383003
This builds, links, and runs on Linux. Have not tried Mac.
I've tested is_debug={true,false} and is_component_build.
It's neat that the component build DM works, but it's also an indication I've missed an essential flag or two... it shouldn't work. :)
The GPU backend isn't working yet, but all the software configurations I've tried look good.
This fleshes out all the other parts of SkCodec too... I noticed we weren't able to decode gifs or webp.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2188643002
Review-Url: https://codereview.chromium.org/2188643002
- Make fiddle build on Mac (skipping GL).
- Now that we're building in SkCodec, we depend on libpng and libjpeg-turbo unconditionally, not just on Linux.
- Re-arrange third_party a bit so that our targets are Fuchsia/Chrome compatible.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2184133002
NOTREECHECKS=true
This doesn't affect Chrome/Blink, so landing through the closed tree.
Review-Url: https://codereview.chromium.org/2184133002
This sketches out what a world without Chrome's GN configs would look like.
Instead of DEPSing in build/, we now host our own gypi_to_gn.py.
The symlink from skia/ to . lets us run gclient hooks when the .gclient file is in the directory above skia/ or inside skia/. That means we don't need gn.py anymore.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2167163002
Review-Url: https://codereview.chromium.org/2167163002
What we've got here is a little GN MVP. It's lacking any knobs and doesn't yet build anything but libskia, zlib, libpng, and libjpeg-turbo. I've been hopping back and forth between Linux at work and Mac at home. These seem to be at least partially working, enough to build and run cmake/example.cpp.
The xcode backend seems to work. From here, we can start exploring how to handle other backends (cmake,Android make, Google3). There are a couple things I want to try:
- add another backend like vs or xcode to GN directly
- intercept via a custom toolchain
- reverse from ninja -t commands
That last option seems kind of fun.
This tries to piggyback on Chrome's GN setup as much as possible. Chrome's got quite a lot figured out, and we're basically required to do this if we want to have a single GN build system shareable by Chrome, our bots, and other clients.
This pulls in some new DEPS:
- build: Chrome's GN configuration, and much more
- buildtools: hashes for gn binary, pulled via hooks
- tools/clang: hashes for Chrome's clang, pulled via hooks into third_party/llvm-build
It additionally symlinks tools/gyp to third_party/externals/gyp. GN pulls some stuff from tools/gyp on Mac.
Have not yet tried building for Windows, Android, or iOS.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2087593002
Committed: https://skia.googlesource.com/skia/+/1d8de594f126b9a80bd8f8fa2005e90faf3b5b17
Review-Url: https://codereview.chromium.org/2087593002
Reason for revert:
gclient not happy on some bots
Original issue's description:
> GN
>
> What we've got here is a little GN MVP. It's lacking any knobs and doesn't yet build anything but libskia, zlib, libpng, and libjpeg-turbo. I've been hopping back and forth between Linux at work and Mac at home. These seem to be at least partially working, enough to build and run cmake/example.cpp.
>
> The xcode backend seems to work. From here, we can start exploring how to handle other backends (cmake,Android make, Google3). There are a couple things I want to try:
> - add another backend like vs or xcode to GN directly
> - intercept via a custom toolchain
> - reverse from ninja -t commands
> That last option seems kind of fun.
>
> This tries to piggyback on Chrome's GN setup as much as possible. Chrome's got quite a lot figured out, and we're basically required to do this if we want to have a single GN build system shareable by Chrome, our bots, and other clients.
>
> This pulls in some new DEPS:
> - build: Chrome's GN configuration, and much more
> - buildtools: hashes for gn binary, pulled via hooks
> - tools/clang: hashes for Chrome's clang, pulled via hooks into third_party/llvm-build
> It additionally symlinks tools/gyp to third_party/externals/gyp. GN pulls some stuff from tools/gyp on Mac.
>
> Have not yet tried building for Windows, Android, or iOS.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2087593002
>
> Committed: https://skia.googlesource.com/skia/+/1d8de594f126b9a80bd8f8fa2005e90faf3b5b17TBR=bsalomon@google.com,mtklein@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2088253002
What we've got here is a little GN MVP. It's lacking any knobs and doesn't yet build anything but libskia, zlib, libpng, and libjpeg-turbo. I've been hopping back and forth between Linux at work and Mac at home. These seem to be at least partially working, enough to build and run cmake/example.cpp.
The xcode backend seems to work. From here, we can start exploring how to handle other backends (cmake,Android make, Google3). There are a couple things I want to try:
- add another backend like vs or xcode to GN directly
- intercept via a custom toolchain
- reverse from ninja -t commands
That last option seems kind of fun.
This tries to piggyback on Chrome's GN setup as much as possible. Chrome's got quite a lot figured out, and we're basically required to do this if we want to have a single GN build system shareable by Chrome, our bots, and other clients.
This pulls in some new DEPS:
- build: Chrome's GN configuration, and much more
- buildtools: hashes for gn binary, pulled via hooks
- tools/clang: hashes for Chrome's clang, pulled via hooks into third_party/llvm-build
It additionally symlinks tools/gyp to third_party/externals/gyp. GN pulls some stuff from tools/gyp on Mac.
Have not yet tried building for Windows, Android, or iOS.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2087593002
Review-Url: https://codereview.chromium.org/2087593002
