https://bugs.freedesktop.org/show_bug.cgi?id=39831

Lionel Elie Mamane <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Whiteboard|                            |target:3.7.0
         Resolution|WORKSFORME                  |---
                 CC|                            |[email protected]
     Ever confirmed|0                           |1

--- Comment #8 from Lionel Elie Mamane <[email protected]> ---
Our build system has changed since I filed this bug...

OK, now we have:

Makefile.top:

src.downloaded : Makefile.top download ooo.lst bin/repo-list
ifeq ($(DO_FETCH_TARBALLS),YES)
        @./download $(SRCDIR)/ooo.lst && touch $@
else
        @echo "Automatic fetching of external tarballs is disabled."
endif


AC_MSG_CHECKING([whether we want to fetch tarballs])
if test "$enable_fetch_external" != "no"; then
    AC_MSG_RESULT([yes])
    DO_FETCH_TARBALLS="YES"
else
    AC_MSG_RESULT([no])
    DO_FETCH_TARBALLS="NO"
fi
AC_SUBST(DO_FETCH_TARBALLS)


The remaining problem is that the auxiliary repositories (dictionaries,
binfilter, ...) are still not cloned when --disable-fetch-external is passed to
autogen.sh, because that's triggered by ./download and ./download is not being
run. According to its documentation, --disable-fetch-external disables only
fetching tarballs from web sources, which I understand as the src/ directory.
(We might decide to change the documentation rather than the implementation
here...)

However, yesterday Norbert pushed to master the "use git submodules for
auxiliary repositories", which *might* have made the "./download run './g
clone' which clones the needed auxiliary repositories in clone/" step obsolete.

However, I see that ./download still calls "./g -f clone" which seems to now
actually do the submodule setup, so it seems to me like it is *still* necessary
that "./g clone" is run on a fresh core clone.

@norbert: could you please confirm/infirm that? Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to