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
