New branch 'private/jmux/oss-fuzz' available with the following commits:
commit 8aec0b0fe69532aff4ee6e530dbe9f7badd238f8
Author: Jan-Marek Glogowski <glo...@fbihome.de>
Date:   Mon Dec 13 18:47:50 2021 +0100

    oss-fuzz: put LO downloads into $SRC/external-tar
    
    Change-Id: I0d5cf89fabc8e044959dbd0af484b5ca46404eac

commit 38ee425cbf1321826896541a3294f5c7cf66508d
Author: Jan-Marek Glogowski <glo...@fbihome.de>
Date:   Sun Dec 12 22:03:49 2021 +0100

    oss-fuzz: convert to static cross-build
    
    This way we can get rid of the pre-generated locale data and the
    special fuzzers target, which invokes a full gbuild make for
    every prereqisite, always parsing the whole tree, taking ages.
    
    This also reverts:
    - commit d0780b21cfe235c4446adf649eb690f9c1771dd5 ("fix oss-fuzz
      build") by adding epubgen and revenge dependencies.
    - commit ff25d6a123beb42476bf42d189b3033a86835b2a ("ofz#41602 fix
      more build failure"), which shouldn't happen anymore since
      commit d47628f287f4377394c4ff488c433bfe254b6abe ("don't want to
      link to system static libs for DISABLE_DYNLOADING")
    
    Change-Id: I3aed9ec62da507254b42e4e7470bae1097b4bc8c

commit cc7eb0b8db3fc5c9f6f799ae622ede5e2152ea9f
Author: Jan-Marek Glogowski <glo...@fbihome.de>
Date:   Fri May 21 15:41:15 2021 +0200

    gbuild: build static LO / link static executables
    
    See the (large) comment in solenv/gbuild/static.mk trying to
    explain, why this implementation was chosen (spoiler: seems
    there is no other way) and what is actually implemented. Yes,
    I also think it's borderline maintainable (like gbuild in
    general; complexity clashing with make "restrictions").
    
    I which I had put that much time into a Meson build, or just
    had expanded the bin/lo-all-static-libs "concept"...
    
    Change-Id: Iafc95752fae9e88095f54a21f1e30a4f080815e2

commit 94d3ee45fc95b21ee671fce0ec00d92d6b44c3dc
Author: Jan-Marek Glogowski <glo...@fbihome.de>
Date:   Wed Dec 15 15:50:42 2021 +0100

    Disallow multiple component files per library
    
    This converts existing users of multiple component files to the
    new filtering mechanism and adds a check to error in the case
    that someone tries to set multiple component files again.
    
    Change-Id: Ie75d6c5d1b78f446ff06faba7350715289b8d17e

commit facd9d13eed6b77c0b2b5616329c593463bba9cf
Author: Jan-Marek Glogowski <glo...@fbihome.de>
Date:   Wed Dec 15 15:37:58 2021 +0100

    Filter optional component implementations by name
    
    Instead of trying to make up BUILD_TYPE items to match complex
    build conditions and then patch the component file with it, filter
    the component files based on the unique implementation name and
    an <optional/> tag. Currently these optional implementations are
    grouped in external files with an identifier.
    Originally the optional implementations were automatically iden-
    tified by adding them to any external file, but this behavior is
    too easy to get wrong. Even better: if need arrises, one can now
    easily implement a feature to add implementation names directly
    using gbuild calls, instead of grouped files.
    
    The basic mechanism is to collect all optional implementations,
    remove the needed ones from that list and then filter-out all
    implementations not needed (AKA the rest of the list).
    It's no problem to have the same optional implementations
    selected in multiple files. This is especially used by the
    vcl.common component in a later patch.
    
    For gbuild this adds gb_Library_add_componentimpl. The component
    parameter for the call is explicitly omitted, so you must call
    gb_Library_set_componentfile before selecting any optional
    implementations. The strict naming is also enforced by appending
    the identifier to the component file name.
    
    This replaces commit 65c0887bca2909b2046eb5aa4aaace0cc320c3f2
    ("Allow for conditional parts of component files").
    
    Change-Id: I0261cadce8bdfebb6b3ec96669ec378a5c1d9699

commit e217e52503a455a769f346ea0cadaee197aa00fc
Author: Jan-Marek Glogowski <glo...@fbihome.de>
Date:   Mon Dec 13 18:21:11 2021 +0100

    gbuild: add gb_CondSalTextEncodingLibrary
    
    Change-Id: I04e8f56bde6296477d449f1c447e8133cdf86e6e

commit 7f7ef6d5157d9d3e0c4a062db99afed8e958e24e
Author: Jan-Marek Glogowski <glo...@fbihome.de>
Date:   Mon Dec 6 17:41:30 2021 +0000

    lockfile: limit usage more strictly
    
    ... and introduce solenv/gbuild/Conditions.mk
    
    Change-Id: Ie4498e12b3d0f676ed0c9abf4b3bb4899d6a1c03

Reply via email to