On Mon, 07 Dec 2009 11:01:02 +0100 Thorsten Behrens <t...@openoffice.org> wrote:
> This is a circular argument. Correct dependencies and the underlying > build/make system used are orthogonal. As an aside, I guess I'm only > questioning the rationale here, not the goal - getting rid of the > build.pl perl hell would be quite appreciated. ;) This is not an issue of correctness of dependencies, its about granularity of build.pl's dependencies. Build.pl dependencies are no finer than a module -- and the smallest build unit it knows about is a directory. > Granted, quite some redundancy results out of OOo's inconsistency on > many levels; Jep. In the long run it would be a good idea to get rid of those and not to work around them in build system. > still, why not encoding that knowledge in one place, > instead of spreading it over umpteen makefiles again? Actually the > current libs.mk does a better job of encapsulating things, compared > to the manual fetch of lib names via OOoLibrary_get*, RTLibrary_get* > etc. That is open to discussion. However, having a centralized library name registry is feeling just as wrong. (I remember saying that I wanted ugly things to be ugly in the build system and not do any cosmetics on them, so that they might be fixed at the root -- once you do cosmetics, you quickly end up depending on the ugliness and thus will never get rid of it.) > # loads cxxflags, weird sw include setup etc. > include sw_defaults Here you will either need to use dirty tricks or you will clash in a global namespace, because you would like these defaults to be applied to msword and others in sw, but not the others. What you could do is something like this: -- file inc_sw_defaults.mk #include guards here define set_sw_defaults $$(eval $$(call gb_OOoLibrary_set_include,$(1),...)) ... endef -- end file sw_defaults -- file target_lib_msword.mk include ....inc_sw_defaults.mk $(eval $(call set_sw_defaults,msword)) .... end file > msword_linklibs=$(extractdeps $(msword_SOURCES)) > > The last line may well be a pipe dream for the while, but at least > in theory, one should be able to glean the needed libs from the > #include statements ... You share that pipe dream with Kay Ramme (and me too). But lets be realistic -- we will have to learn to crawl before we try running. > > So a generated project file might introduce subtle different builds, > > is dependent on the version of the generator and is read-only. > > Since you can "generate a project from existing code" trivially in > > NetBeans, Visual Studio and others and just as well kick of a > > makefile-based build in all modern IDEs, what exactly is gained by > > generated project files? > > > If that gives the same developer experience - sure. I'd then be > interested in some pointers inside the wiki's build guide. ;) Will be considered. However, for the bigger modules like sw having just one module (and headers from solver) in the IDE can be really slow. Still, for stuff like renaming a method with a hard-to-grep/sed name (hmmm, like "Update" or "Modify") it might be worth it. > Would then be interesting to know how implicit rules are treated > inside gnu make (i.e. whether each instantiation counts) - we'd be > in that ballpark easily, with some 11k cxx files & what else comes > on top. Pattern rules definitely scale different than explicit rules for each target. One thing I will have to watch out for are variable scopes. However, we do not need a variable scope per cxx file -- in most cases only the linking targets (the libraries) have a variable scope and those are not so many that it would scare me. Still, I will do some (synthetic) test on those too. > Prior art: > http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-IMSA92/for-web.pdf Pfft, thats easy. There is always prior art at Xeroc PARC. ;-) > And in fact inescapable, ~every implementation will leak under its > abstractions. So I guess you're rather arguing for having only _one_ > implementation - which is not obtainable in a cross-platform, > opensource project. ;) No, I am all for (according to the Zen of Python): "There should be one-- and preferably only one --obvious way to do it." Best Regards, Bjoern Michaelsen -- =========================================================================== 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
