Difference between revisions of "Hacking"
Rickpastoor (Talk | contribs) |
m (→Sending patches: Added links.) |
||
Line 42: | Line 42: | ||
cat CVS/Repository | cat CVS/Repository | ||
framework/binfilter | framework/binfilter | ||
− | This shows you that the 'binfilter' directory is part of the 'framework' project. | + | This shows you that the '[[Framework/Modules/binfilter|binfilter]]' directory is part of the [[Framework|'framework' project]]. |
These days there is a [http://qa.openoffice.org/issue_handling/submission_gateway.html#code_module hackers bug filing page] that will assign bugs to the correct project, and the correct owner to get rapid attention. | These days there is a [http://qa.openoffice.org/issue_handling/submission_gateway.html#code_module hackers bug filing page] that will assign bugs to the correct project, and the correct owner to get rapid attention. |
Revision as of 09:00, 2 February 2007
ContentsMy first hackSo - we've built and run OO.o, and we want to prove to ourselves that it is in fact possible to hack on it. So in a new terminal do this: cd build/src680-m66 . ./LinuxIntelEnv.Set.sh cd vcl Now have a hack at vcl/source/window/menu.cxx (Menu::SetItemText); (near line 1770) I suggest manually applying this change: - pData->aText = rStr; + pData->aText = String(rStr).Reverse(); Then save. ( You can find more sensible things to hack in the Tutorials ) You're still in vcl/ yes ? then type 'build debug=true'; wait for the scrolling text to stop; (5 seconds?). Now re-run
Note: for day to day hacking you want to just run 'build' inside the source tree. It is also highly recommended to work inside a copy of the build tree, and generate / test patches in an un-hacked version. To copy just the build/src680-m66 directory elsewhere, you need to use the relocate tool. Read the Fine manualWith the power of C++ comes the ability to shoot yourself in the foot all the more easily; (and implicitly), cf. Holub, Rules for C and C++ programming, McGraw-Hill, 95. The best way to prepare yourself for battle is to read the OpenOffice coding guidelines, and for the easily confused c'tor / d'tor is short for constructor / destructor. Also, there's an extensive list of recommended literature about C++ - but that's of course no prerequisite to start coding. Sending patchesThe toplevel structure of the OO.o source code is not the same as the layout of the CVS repository [ a good rational for this strange state of affairs is absent ]. Thus to work out what real module a file is in you need to do eg. cd binfilter cat CVS/Repository framework/binfilter This shows you that the 'binfilter' directory is part of the 'framework' project. These days there is a hackers bug filing page that will assign bugs to the correct project, and the correct owner to get rapid attention. Starting the right app
As you start soffice.bin, there are several useful parameters to
use to accelerate your debugging experience; particularly
Understanding D' make (man)While the build system is in similar to many other systems, it is also perhaps slightly different. The overview is that each module is built, and then the results are delivered into the solver. Each module builds against the headers in the solver. Thus there are a few intricacies.
Standard directoriesThere are various standard directories and files in most of the modules that make up OO.o, here are some of the more useful:
Build's mode of operation is to invoke 'dmake' in each of the projects' directories with a given dependency order. dmake then executes the rules in makefile.mk. prj/build.lstOn first view build.lst looks scary: vc vcl : NAS:nas FREETYPE:freetype psprint rsc sot ucbhelper unotools sysui NULL vc vcl usr1 - all vc_mkout NULL vc vcl\source\unotypes nmake - all vc_unot NULL vc vcl\source\glyphs nmake - all vc_glyphs vc_unot NULL ... vc vcl\mac\source\src nmake - m vc__srcm vc_unot NULL vc vcl\util nmake - all vc_util vc__plug.u vc__appa.u vc__appm.m vc__appu.u vc__appw.w vc__gdim.m vc__gdiu.u vc__gdiw.w vc__srcm.m vc__srcu.u vc__srcw.w vc__wina.u vc__winm.m vc__winu.u vc__winw.w vc__du.u vc__gtka.u vc__gtkw.u vc__gtkg.u vc__kde.u vc_app vc_ctrl vc_gdi vc_hlp vc_src vc_win vc_glyphs NULL so we need to try and un-pack what's going on here, which is in fact not as odd as it might seem at first glance. Firstly lists are terminated by the 'NULL' string. Every line is prefixed by a shortcut which has to be unique, no two modules are allowed to have the same shortcut.
So we see in the vcl case that vcl\source\unotypes (vc_unot) has to be built before vcl\source\glyphs (vc_glyphs). For Mac vcl\mac\source\src (vc__srcm) has to be built before vcl\util (vc_util) It is important to understand that the order of the list is ~immaterial, and instead of a simple ordered list, we have a more complex internal dependency system — this contrasts with most other make systems. There is also documentation here on it. deliver, deliver.log and prj/d.lstThe syntax of d.lst is more comprehensible than build.lst, it omits some default actions, such as copying build.lst into inc/<module>/build.lst.A line is of the form: [action]: [arguments] mkdir: %_DEST%\inc%_EXT%\external where if '[action]:' is omitted, it defaults to the 'copy' action. Typical actions are copy, mkdir, touch, hedabu, dos and linklib. The 'hedabu' action is particularly interesting, inasmuch that it cosmetically re-formats the header to shrink it on install and adds the module name to the include path (#include "my_header.hxx" becomes #include <my_module/my_header.hxx>). Otherwise it's much like the copy action. During the action, various macro variables are expanded some of which are:
Typically then, if indeed you need to add a rule (cf. implicit directory copies), it will be of the form: ..\%__SRC%\inc\sal\*.h %_DEST%\inc%_EXT%\sal\*.h NB. relative paths are relative to the 'prj/' directory. Sometimes you might run into the situation where you'd like to remove the delivered files from solver. Your configuration might have changed and they are no longer needed. "deliver -delete" does just that, however you might still need to delete "deliver.log" files manually as well. Can I get a
|
|