Re: [tools-dev] Re: Building OpenOffice.org with GNU make
On Tue, 12 Jan 2010 17:37:59 +0200 Jussi Pakkanen wrote: > On Tue, Jan 12, 2010 at 12:35 PM, bjoern michaelsen - Sun Microsystems > - Hamburg Germany wrote: > > One dependency less (because you will need an additional "native" > > build system like GNU make or MS Build anyway). > > Well yes, but you add a build-dependency to Python (if there isn't one > already, I don't know). In a way there is, because of Mercurial. But I am also uncomfortable to depend on Python for the build. > Even if you ignore that, there is a dependency to either an external > build tool or to a custom build script thing. Choosing which way to go > should be naturally done by the people who have to use/maintain them. See my reply to Thorsten. I think the translation from a simple syntax to the makefile syntax is possible with quite a few tools we will already have as a dep, for example: - bash or even POSIX sh - the C preprocessor - GNU make itself > No, CMake is a replacement for Autoconf + Automake. Neither "builds > anything by themselves" but rather produce output for a lower level > tool (e.g. Make). A modern Make does not have to be low level at all. > Using CMake only for configuration is doing things very wrong. I guess > you could do it if you really, really wanted to but it is going to be > hard and counterproductive. "One job, one tool" has been proven time and again to be a Good Thing(tm). But that is a philosophical -- or even sophistic -- discussion we should postpone until all editor flamewars have been resolved. ;) Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
On Tue, Jan 12, 2010 at 12:35 PM, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: >> What is the benefit you get from this instead of using something like >> CMake that already has a mature implementation of this functionality? > One dependency less (because you will need an additional "native" > build system like GNU make or MS Build anyway). Well yes, but you add a build-dependency to Python (if there isn't one already, I don't know). Even if you ignore that, there is a dependency to either an external build tool or to a custom build script thing. Choosing which way to go should be naturally done by the people who have to use/maintain them. > I would consider that to be an option. Actually I think it is wrong to > describe CMake as a build system as it does not build anything itself. > CMake is a replacement for autoconf and should be considered as such in > first place. No, CMake is a replacement for Autoconf + Automake. Neither "builds anything by themselves" but rather produce output for a lower level tool (e.g. Make). Using CMake only for configuration is doing things very wrong. I guess you could do it if you really, really wanted to but it is going to be hard and counterproductive. > That being said, I have seen the GNU makefiles that are > being generated by CMake and their readability is horrible. If > something goes wrong there, it is really hard not only to debug the > makefile (for bugs in cmake itself), but it is also hard to just "trace > the error" from the errormessage of the native build system to the > sources (for bugs in the description given to cmake). This is a fair point. Anecdotally, I have used CMake on several different projects and have never had the need to look into the generated files, they have just worked. Then again, OOo has the tendency to break tools just by its sheer size. :) - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
[tools-dev] tools.openoffice.org webpage cleanup
Hi list, can somebody from the tools project clean up the webpage at tools.openoffice.org? It is prominently linked from the page http://contributing.openoffice.org/programming.html, where dev newbies likely end up by the click path from the frontpage "I want to participate ... -> Programming". IMHO the page could need: - A big, fat link to the building guide in the wiki on the top (esp. in front of the background info which is way to detailed for a newbie) - Removal of the "Downloading from CVS/Subversion pages" -- just link to the wiki, it is more up to date. - Removal of the links to the static Linux and Windows Build instructions pages, that are better maintained in the Wiki and should not be duplicated here. - Removal of the coding guidelines, which are duplicated and better maintained on the Wiki. tl;dr: Can we consolidate duplicate information on static pages into the wiki? Opinions? BR, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
On Mon, 11 Jan 2010 16:05:57 +0200 Jussi Pakkanen wrote: > I would like to point out that what you are doing is generating your > own language and a build tool/generator based on that. There's nothing > wrong with it as such, but this is reinventing the wheel again (just > like Google's GYP). Instead of custom dmake/build.pl you would have > custom gnumakegen/gnumake_or_something. There is a huge difference between dmake/build.pl and the GNU make prototype. The current GNU make prototype (although incomplete) is a clean <1KLOC implementation including thb's stuff. The current dmake/build.pl toolchain is >38KLOC and pretty hard to maintain. > What is the benefit you get from this instead of using something like > CMake that already has a mature implementation of this functionality? One dependency less (because you will need an additional "native" build system like GNU make or MS Build anyway). > Even if CMake eventually turns out to be too slow, would it not make > more sense to write your own custom CMake back end rather than the > configuration/generation front end? I would consider that to be an option. Actually I think it is wrong to describe CMake as a build system as it does not build anything itself. CMake is a replacement for autoconf and should be considered as such in first place. That being said, I have seen the GNU makefiles that are being generated by CMake and their readability is horrible. If something goes wrong there, it is really hard not only to debug the makefile (for bugs in cmake itself), but it is also hard to just "trace the error" from the errormessage of the native build system to the sources (for bugs in the description given to cmake). Best Regards, Bjoern -- === Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering === - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: > > But the actual information contained in the above lines is actually > > this: > > > > rscdep source files: tools/bootstrp/* > > rscdep link libs: tl > Quoting a band from Hamburg: "Jein" (=Yes and No). > Of course, there is a lot of superfluous syntax in the current > description, but you are dropping some information too: > - Where is the information which naming convention the tl-lib is > following? > That information is implicitely already contained in the name 'tl'. As you notice further down, the gmakegen script has a static map for those lib names. > - What about the files in tools/bootstrp, that are not generating > object files that should be liked into rscdep (sspretty.cxx for > example)? > Yeah, badly chosen example. The absolute majority of OOo code _is_ organized in a fashion that allotting sources files to libs works on a per-directory basis. At any rate, the generator script can do both. Regarding your point of _where_ the globbing should take place: currently it's run from the generated makefile, so your thoughts on when to re-run the generator don't apply. ;) > > [makefile generator input] > > > > What do you think? > Looking a lot better that the GNU make input files, that are currently > used in the GNU make prototype for sure. However, I wonder how the > deeply nested lists and maps of python are looking to the > (python)-untrained eye. Subjecting an unsuspecting colleague to the > syntax will tell, I guess. > Thanks. :) So, unsuspecting colleagues with the python-untrained eyes: what would be your take on this? > Another thing to be considered with this is the introduction of python > as a dependency that early in the toolchain. AFAIK currently we have > these dependencies for the build system: > > [snip] > Generally a worthy goal to reduce dependencies; though of little practical relevance here IMHO. FWICT python has a broader supported base than java, and I think we're past this phase of having _that_ being an optional build requirement, do we? ;) Additionally, hg needs python anyway. > Given that the syntax of the "build task description language" should > be simple (because, if one needs it to be complex, one is likely Doing > It Wrong(tm)) I wonder, if something that can be processed by the > POSIX-shell or the C-Preprocessor would not be possible too(*). > Actually, I am rather confident that would be possible. > Likely. There are two reasons I decided against using those: * ugliness (I have yet to see the cpp macro program that does not hurt my eyes) * too much expressiveness (you'll get full turing completeness easily, when you process stuff with the shell. I explicitely wanted to keep things declarative, and prohibit those small local if-then-else workarounds) > Still, there remains the problem with makefile generation (when? what > are the dependencies? does the generator glob for files or does the GNU > make build system do this?), which I guess we should discuss first, > because "All problems in computer science can be solved by another > level of indirection except for the problem of too many layers of > indirection." > Sure. :) So, for my current draft, the gnu make system does it. For a future visual studio project generator, I guess the generator script would have to do that. Both approaches are valid in their respective area, I think. Whether the former might pose performance issues remains to be seen, but would have an easy fix (just fix the generator. having gnu makefiles as the authoritative input would make that much harder). Cheers, -- Thorsten pgpWb5TN0x6CQ.pgp Description: PGP signature
Re: [tools-dev] Re: Building OpenOffice.org with GNU make
On 01/11/10 23:44, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: Am Mon, 11 Jan 2010 18:04:21 +0100 schrieb Stephan Bergmann : Which, at least in its simplest form, would imply that it necessarily modifies the source tree by adding files to it, something I personally would prefer moving away from. No. Generated makefiles are _generated_ and thus not source files. They shouldnt be generated to the read-only source tree, but reside in the workdir (those dirs with are located at $MODULE/$PLATFORM in the current build system, but they would not be in the source tree in a new build system). Good to hear you have that on your agenda. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
