Development/FAQ/da

Hvordan "afluser" (debugger) jeg LibreOffice?
Det kritiske punkt er at passere --enable-debug to autogen.sh. Find oplysninger og hjælp på Udvikling/Hvordan debugger jeg.

Hvad betyder de der #iXXXX#/fdo#XXXX/etc. kommentarer?

 * #XXXXXXX# henviser til StarDivisions interne fejlsporing, og er ikke offentlig tilgængelig, så det kan lige så godt fjernes fra kilden
 * b#XXXXXX# henviser til Suns interne fejlsporing, og er ikke offentlig tilgængelig, så det kan lige så godt fjernes fra kilden
 * cp#XXXXXX henviser til Collaboras interne fejlsporing, og er ikke offentlig tilgængelig, så det kan lige så godt fjernes fra kilden
 * #iXXXXXX# eller i#XXXXXX henviser til OpenOffice.org/Apache Open Offices bugids, fx henviser #i100000# til https://issues.apache.org/ooo/show_bug.cgi?id=100000
 * rhbz#XXXX henviser til RedHats bugids, fx henviser til https://bugzilla.redhat.com/show_bug.cgi?id=680460
 * #nXXXXXX# eller n#XXXXXX eller helst bnc#XXXXXX henviser til Novells bugids, fx henviser #n672421# til https://bugzilla.novell.com/show_bug.cgi?id=672421
 * fdo#XXXXX henviser til Freedesktop.org's bugids, fx henviser til https://bugs.freedesktop.org/show_bug.cgi?id=32275
 * Dette omfatter ikke-LO fejl, som er relevante for LO, fx og gamle LibreOffice fejl (før januar 2015)
 * tdf#XXXXX henviser til The Document Foundation’s eget miljø på Bugzilla, fx henviser til https://bugs.documentfoundation.org/show_bug.cgi?id=32275
 * lp#XXXXXX henviser til launchpad, fx: https://launchpad.net/bugs/775608
 * abi#XXXXXX henviser til AbiSource (Abiword)s fejlsporing, fx: http://bugzilla.abisource.com/show_bug.cgi?id=123456
 * boost#XXXXXX henviser til Boost's fejlsporing, fx: https://svn.boost.org/trac/boost/ticket/123456
 * deb#XXXXXX henviser til Debian's fejlsporing, fx: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=123456
 * gnome#XXXXXX henviser til Gnome's fejlsporing, fx: https://bugzilla.gnome.org/show_bug.cgi?id=123456
 * icu#XXXXXX henviser til ICU's fejlsporing, fx: http://bugs.icu-project.org/trac/ticket/123456
 * kde#XXXXXX henviser til KDE's fejlsporing, fx: https://bugs.kde.org/show_bug.cgi?id=123456
 * moz#XXXXXX henviser til Mozilla's fejlsporing, fx: https://bugzilla.mozilla.org//show_bug.cgi?id=123456
 * py#XXXXXX henviser til Python's fejlsporing, fx: https://bugs.python.org/issue123456
 * ofz#XXXXXX henviser til OFZs interne sporing (Google OSS fuzzer, see https://github.com/google/oss-fuzz ) (fejlsporing, offentligt tilgængelig efter nogle få dage/uger på chromium.org)
 * cid#XXXXXX eller coverity#XXXXXX henviser til Coverity Bugs.

Hvad er alle de tests: enhedstests, røgtests, efterfølgende tests?
Spørgsmålet blev besvaret af Bjoern Michaelsen i en post på maillisten: http://lists.freedesktop.org/archives/libreoffice/2011-March/009834.html

Et "make check" på top-niveau bygger et fuldstændigt program og kører så alle de efterfølgende tests, men en et "make subsequentcheck" på top-niveau udelukkende kører alle de efterfølgende tests.

Mere information om enhedstests (på engelsk) skal findes her og om efterfølgende tests: her.

Smoketesten mislykkedes, hvordan fejlsøger jeg det
Hvis dev-install eller bygning af smoketestoo_native mislykkes, forbliver den installation, hvis smoketest mislykkedes, i Du kan køre smoketesten manuelt og se på pæne grøn/røde rapportceller, for at se nøjagtig hvad, der mislykkedes. slå makrosikkerhed, fx, fra og luk Office klik på knappen Start smoketest

Et andet alternativ er at starte  allerførst og lade smoketesten oprette forbindelse til denne kørsel i stedet for at starte en selv (se ). Derefter kan du køre  under fejlsøgerkontrol. Det eneste problem er, at  normalt vil overskrive den , der lige blev startet med et nyt installationssæt på grund af afhængigheden af   på   i. Så noget som det følgende skulle virke:

Jeg vil gerne bygge LibreOffice, men jeg er kun interesseret i Writer. Kan jeg udelukkende bygge Writer uden resten?
Det korte svar er Nej.

Det lange svar er, at de individuelle programmoduler i LibreOffice (Writer, Calc, Draw, Impress osv.) har meget delt kode, så at den øverste del af modulet består af kun mindre end 10% af hele koden. Så selvom du på en eller anden måde klarede ikke at bygge noget af disse programmer, ville det ikke reducere den samlede byggetid.

Dertil kommer, at hele pakken er designet med den antagelse at alle programmoduler altid er tilstede. Så hvis nogle af programmerne ikke findes, kunne det skabe nogle helt tossede, slemme problemer, som ingen anden ville kunne hjælpe dig med.

Under Windows mislykkedes bygningen med en intern fejl i kompileren
fatal error c1001: An internal error has occured in the compiler Du skal tjekke, om du har den seneste opdatering af Visual Studio.

Tjek opdateringen på Microsoft search.