On Fri, Jan 17, 2014 at 9:59 AM, Kay Schenk <kay.sch...@gmail.com> wrote:
> > > On Fri, Jan 17, 2014 at 12:26 AM, Andre Fischer <awf....@gmail.com> wrote: > >> I would like to present some ideas about how to improve the >> building of OpenOffice. Maybe this can serve as a basis for a >> face-to-face discussion at FOSDEM. >> >> Makefiles in general and our build environment in particular have a >> declarative and an imperative part. In short dependencies are declared >> and build recipes are given as instructions. This is reflected by >> both our build systems. For dmake we have makefile.mk files in all >> source directories. They contain basically the names of libraries to >> build and c++ files to compile. The recipes that define how to link >> and compile are located in solenv/inc/. This is similar for gbuild. >> There are a couple of makefiles (named Makefile, Module...mk, >> Library...mk and so on) in the top level module directories. They >> also just declare the set of files to compile or link. The gbuild >> recipes can be found in solenv/gbuild/. >> >> This observation together with my (our) unhappiness of the current >> state of our build systems lead me to the following "insight". One >> obstacle when playing around with other build tools, like cmake or >> ninja or just plain GNU make makefiles (as opposed to our >> meta-programming gbuild files) is the syntax of how our dependencies >> are declared. It would be so much easier when they would be stored in >> a file format that is both machine and human readable and not tied to >> one specific program. >> >> What if we used XML files to represent the dependencies? We could >> convert the gbuild makefiles into XML files with very similar >> structure. A simple Perl script or Java program (both understand XML >> and are part of our build prerequisites) can convert the XML file to >> gbuild files that would be almost identical to what we have today. >> And when we want to try alternatives, we can provide other converters >> and make experiments. See [2] for an example. >> >> Such a converter could be more complex than just do a simple syntax >> translation. For using ninja [1], which is described as "assembler" >> and has no %.o : %c rules and no if/else/fi, we would need more than >> that. But still less than cmake because our compiler (and other build >> tool) detection is done by configure. >> >> Using XML files would probably not much of an overhead. The >> translation into makefiles has to be done only when the makefile/XML >> representation changes. The additional dependencies, one per current >> makefile (less than 10 in the average module), are negligible compare >> to the dependencies for several hundreds of source files and several >> thousands of headers. >> >> But again, this is not (yet) a proposal for change. >> Just the basis for discussion. >> It is also not (yet) a non-proposal for changing the build system >> completely. >> Just the idea to express our "business logic" in a way that is >> independent from the build system (whichever we use/will use). >> >> >> Best regards, >> Andre >> >> > Any move to making tracking dependencies (build setups) for the modules > better/easier is a move in the right direction. We have quite an > inconsistent mix right now. Look at what's in /connectivity vs /comphelper > as an example. > > Discuss away! :) > I've had a bit more time to think about this and do some investigation. Using XML files for specs does seem like a nice way to go and would open up some other administrative options for us. This so reminded me of ant but for C++, I started looking around...and yes, there are some ant building tools for C++ out there -- commercial not open source -- but I know this isn't what you meant really. Anyway, I look forward to hearing more about this. > > >> [1] http://martine.github.io/ninja/manual.html >> [2] Excerpt from sw/Library_sw.mk: >> $(eval $(call gb_Library_add_linked_libs,sw,\ >> avmedia \ >> basegfx \ >> comphelper \ >> ... >> vcl \ >> vos3 \ >> xo \ >> $(gb_STDLIBS) \ >> )) >> >> >> $(eval $(call gb_Library_add_exception_objects,sw,\ >> sw/source/core/SwNumberTree/SwNodeNum \ >> sw/source/core/SwNumberTree/SwNumberTree \ >> sw/source/core/access/acccell \ >> ... >> sw/source/ui/wrtsh/wrtsh3 \ >> sw/source/ui/wrtsh/wrtsh4 \ >> sw/source/ui/wrtsh/wrtundo \ >> )) >> >> -> >> >> <library="sw"> >> <linked-libraries> >> <library-reference name="avmedia"/> >> <library-reference name="basegfx"/> >> <library-reference name="comphelper"/> >> ... >> <library-reference name="vcl"/> >> <library-reference name="vos3"/> >> <library-reference name="xo"/> >> <library-reference variable="gb_STDLIBS"/> >> </linked-libraries> >> <source-files language="c++" exception_handling="yes"> >> <file name="sw/source/core/SwNumberTree/SwNodeNum.cxx"/> >> <file name="sw/source/core/SwNumberTree/SwNumberTree"/> >> <file name="sw/source/core/access/acccell"/> >> ... >> <file name="sw/source/ui/wrtsh/wrtsh3"/> >> <file name="sw/source/ui/wrtsh/wrtsh4"/> >> <file name="sw/source/ui/wrtsh/wrtundo"/> >> </source-files> >> </library> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> > > > -- > > ------------------------------------------------------------------------------------------------- > MzK > > "Cats do not have to be shown how to have a good time, > for they are unfailing ingenious in that respect." > -- James Mason > -- ------------------------------------------------------------------------------------------------- MzK "Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect." -- James Mason
