On Wed, Mar 16, 2011 at 5:01 PM, Christina Roßmanith
<ChrRossmanith@web.de> wrote:
Hi,
I've edited parhtml.cxx in ./svtools and now I'd like to test if the
modification fixes bug 34666. What do I have to do? Is a partial build in
directory ./svtools enough? Or is there some "install"-step needed? Or do I
have to do a toplevel make?
If you've just changed a .cxx
AND
the thing that need to be rebuilt is not a static library (most targets are not)
then just doing a module level 'build' (1), followed by a 'deliver'
for good measure should be fine
(I'm assuming that you did a dev-install to test, so you don't even
need to do anything else after the build + deliver;
just re-run.)
Now, if you changed a header that is delivered - that is a header that
is possibly used by other module down the line
then you are better off doing a simple make at the top level. How do I
know it is a delivered header, you ask?
well if it is in <module/inc/<xxxx>/* it very, very likely is,
otherwise it _usually_(2) is not.
In doubt, do a top level make (if you are really curious, check the
<module>prj/d.list file to see what actually get delivered, or
<module>/Package_inc.mk for gnu-make converted modules).
If the module you changed is a static library, also a simple make at
the top level will to the trick - except if there is a
dependencies tracking bug, which cause on module down the line to to
be re-link when it should.
Of course since that would be a bug to start with, there is no 'rules'
as to when that can be a problem... it's just known to have happened
;-)
Once you graduate to the Caolan-style mastery of the intricacy of the
interdependence of modules, then you can probably know which
modules are directly and indirectly impacted with any of your changes
and rebuild them individually, but for mere mortal like you and me, a
top level make is much safer/easier :-D
So in the specific case you mentioned, a module level 'build' followed
by 'deliver' should be all you need.
Norbert
(1): as a, hopefully useful, reminder for all my fellow apprentice
hackers. what I mean by "module level build' is explained here ->
http://wiki.documentfoundation.org/Development/Native_Build#Partial_build
(2) that rules will become much more strict as modules are converted
to the soon-to-be-in-master gnumake
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.