William Kyngesburye wrote: > >> I sortof understand this. Until you can work out the necessary > >> changes (if you decide to), how about some minimal changes to the the > >> extension compilation working? > > > > Unfortunately, use of the "get it working for now" approach is > > responsible for much of the current mess. I'd rather take the > > opportunity to improve matters than to make them worse. > > OK. I guess I'm just being a bit impatient. > > So, you're working on this now? ;) Or will get to it?
The latter. I have "Makefile fatigue" right now, and I want to allow people to find any bugs in the most recent bunch of changes. > >> - grass.make.in: add at end: > >> > >> ifdef INST_XTN > >> include $(MODULE_TOPDIR)/include/Make/Install_xtn.make > >> endif > >> > >> and have a new Install_xtn.make fragment. This is just a trimmed > >> version of the main makefile with just install targets and any > >> unnecessary bits removed. It expects INST_DIR_XTN to be set in the > >> make command. > > > > I'm not sure that this needs to be conditionalised. If there are parts > > of the top-level Makefile which might be useful to extensions, they > > should be moved into one of the *.make files (or a new file). > > > > In general, the *.make files should define as much as possible > > unconditionally, and leave it up to either individual Makefiles or the > > user to decide what actually gets used. > > Just to make sure: the main makefile's install target will override > that makefile frag's install target, in a normal build, since the > main makefile defines it after this frag is included? GRASS' top-level Makefile only includes Grass.make and Platform.make. It doesn't include any of the other *.make fragments. In general, try to avoid relying upon overriding rules which are defined in the *.make files. Sometimes, overriding rules is unavoidable (e.g. some modules which don't understand --html-description have to override the htmletc target), but it's best not to rely upon it. Apart from printing a warning (which adds "noise" to the build output), if the two versions have both dependencies and commands, the dependencies get merged (sometimes in ways which make the value of $< etc unpredictable) but the commands get overridden. Also, whenever the generic rule is updated, you often end up having to manually update any local versions. [E.g. I've just extended the "clean" rule to allow a list of subdirectories to be specified as CLEAN_SUBDIRS. Previously, r.terraflow, r.le.setup and v.clean were overriding the clean target to handle subdirectories, which meant that they weren't deleting the $(PGM).tmp.html file.] -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
