Cannot build Skia

[Regina Henschel]

Hi Christian,

it does not work for me.

There was a missing bracket. So I have used
sh -c "cd $(shell cygpath -ml $(BUILDDIR)); $(if $(MSYSTEM),$(WSL)
)$(SRCDIR)/autogen.sh"

Then after making the suggested changes, I run autogen.sh.
After that I see again the changed Makefile files and the bogus 
include/include file.

My autogen.sh is
c:/BuildLO4/core/autogen.sh \
--with-external-tar=c:/BuildLO4/externalsrc \
--with-junit=c:/cygwin64/junit/junit-4.10.jar \
--with-ant-home=c:/cygwin64/ant/apache-ant-1.9.5 \
--disable-ccache \
--enable-pch \
--with-visual-studio=2022 \
--enable-dbgutil \
--enable-werror \
--enable-odk \
--disable-cve-tests \
--disable-online-update \
--without-fonts \
--with-jdk-home=c:/BuildLOAdds/jdk \
--enable-python=fully-internal \
PKG_CONFIG=C:/BuildLOAdds/pkg/pkgconf-2.4.3.exe

What information can help you to determine what goes wrong for my build?

Kind regards,
Regina


Christian Lohmaier schrieb am 03.07.2025 um 14:33:
> Hi Regina,
> 
> On Mon, Jun 30, 2025 at 9:37 PM Regina Henschel <rb.henschel at t-online.de> wrote:
>>> Christian Lohmaier schrieb am 30.06.2025 um 13:26:
>>> On Mon, Jun 30, 2025 at 12:46 PM Regina Henschel
>>> <rb.henschel at t-online.de> wrote:
>>>>
>>>> but the next clean build again fails to build skia :(
>>>
>>> Hmm. If you didn't say you already started with a fresh clone, I would
>>> have suspected https://gerrit.libreoffice.org/c/core/+/180511 to be
>>> missing/the cause of the problem.
>>> At least that would match the works the first time, but not subsequent
>>> times (after rerunning of autogen.sh is triggered by make and not
>>> manually) >
>>> So please double-check the status of the <module>/Makefile files in
>>> the checkout. If there's confusion about builddir vs srcdir because of
>>> short forms of paths being different than what was used when running
>>> the initial configure, autogen.sh would replace the makefiles in the
>>> srcdir (while it is only supposed to create copies in a separate
>>> builddir)
>>
>> All Makefile files are altered. For example for folder 'filter':
>> […]
> 
> That matches the symptoms of mistreating a build in the
> source-directory as a build in a separate directory.
> So apparently it is not wsl-specifc (anymore?)...
> 
>>> The fix is only addressing the wsl-as-helper case, since at least my
>>> version of cygwin was unaffected, cygwin-perl's realpath would have
>>> rewritten a shortened path to the long form – but maybe that
>>> assumption is wrong and it needs the same fix.
>>
>> Can you sent me the needed changes, so that I can test it?
> 
> It is the fix in https://gerrit.libreoffice.org/c/core/+/180511 basically.
> To fix the current situation: reset the makefiles to their initial state:
> git checkout -- */Makefile external/*/Makefile
> remove the bogus double-include link
> rm include/include
> 
> git status should not show any touched Makefiles anymore
> 
> Then to fix the problem from reappearing: change Makefile.in to have a line
> $(BUILDDIR)/config_host.mk : SRCDIR:=/$(shell cygpath -ml $(SRCDIR))
> above the ifneq ($(MSYSTEM),) line and change
>      sh -c "$(if $(MSYSTEM),cd $(shell cygpath -ml $(BUILDDIR)); $(WSL)
> )$(SRCDIR)/autogen.sh"
> to
>      sh -c "cd $(shell cygpath -ml $(BUILDDIR)); $(if $(MSYSTEM,$(WSL)
> )$(SRCDIR)/autogen.sh"
> 
> i.e. move the $(if $(MSYSTEM,) wrapper behind the cd / to only contain
> the $(WSL) prefix.
> 
> manually run autogen.sh again, since otherwise the old rule from the
> generated Makefile would be run and recreate the messup.
> 
> The fix is to use the long form of SRCDIR and the long form of
> BUILDDIR, so that if autogen.sh compares them they will
> match/autogen.sh will recognize they are the same directory.
> Since the Makefile at that point doesn't know about any OS or other
> variables from config_host.mk the proper fix is probably to move the
> path-normalization to autogen.sh
> 
> anyhow to trigger the failure prior to fixing and verifying that the fix worked:
> touch autogen.input
> make fetch
> → that will trigger the rerun of autogen.sh by the makefile without
> spending time trying to build something/the make fetch should finish
> quickly in any case.
> then check whether the Makefiles have been modifier/whether there's
> the double include-link.
> 
> ciao
> Christian
>