I just noticed that when I ported r.support, I may have not written the
makefiles properly.
I just realized that commands in etc/support/ are also copied to etc/ as
well. (modcats, modcolr, modhead, modhist)
Could someone review the makefiles in raster/r.support/... and let me
know how to correct this minor problem? I fail to see the problem.
Thanks!
--
Brad Douglas <rez@touchofmadness.com>
On Mon, Aug 08, 2005 at 03:05:29PM -0700, Brad Douglas wrote:
I just noticed that when I ported r.support, I may have not written the
makefiles properly.I just realized that commands in etc/support/ are also copied to etc/ as
well. (modcats, modcolr, modhead, modhist)Could someone review the makefiles in raster/r.support/... and let me
know how to correct this minor problem? I fail to see the problem.
Inspired by db/base/Makefile I suggest the attached example.
Markus
Makefile (390 Bytes)
Brad Douglas wrote:
I just noticed that when I ported r.support, I may have not written the
makefiles properly.I just realized that commands in etc/support/ are also copied to etc/ as
well. (modcats, modcolr, modhead, modhist)Could someone review the makefiles in raster/r.support/... and let me
know how to correct this minor problem? I fail to see the problem.
I suggest replacing:
$(INSTALL) -m 755 $(ETC)/$(PGM) $(ETC)/support
with:
mv $(ETC)/$(PGM) $(ETC)/support/
I wouldn't recommend adding an explicit linking command (i.e.
a copy of the rules for the "etc" target). If the linking command
changes, we want to be able to just change Module.make, and not have
to search all of the Makefiles for private copies.
Actually, is there any reason the programs need their own subdirectory
and can't just go directly into $(ETC)?
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, 2005-08-09 at 16:03 +0100, Glynn Clements wrote:
I suggest replacing:
$(INSTALL) -m 755 $(ETC)/$(PGM) $(ETC)/support
with:
mv $(ETC)/$(PGM) $(ETC)/support/Actually, is there any reason the programs need their own subdirectory
and can't just go directly into $(ETC)?
No particular reason it couldn't go in $(ETC). I put it in
$(ETC)/support to keep $(ETC) uncluttered and easy to identify programs
associated with r.support.
Of course, I could just rewrite r.support to not use these all together
and just have one binary called r.support. That is probably the optimal
solution.
Let me know if you would prefer them go in $(ETC) or if I should
reorganize r.support as a single binary.
--
Brad Douglas <rez@touchofmadness.com>
Brad Douglas wrote:
> I suggest replacing:
>
> $(INSTALL) -m 755 $(ETC)/$(PGM) $(ETC)/support
> with:
> mv $(ETC)/$(PGM) $(ETC)/support/
>
> Actually, is there any reason the programs need their own subdirectory
> and can't just go directly into $(ETC)?No particular reason it couldn't go in $(ETC). I put it in
$(ETC)/support to keep $(ETC) uncluttered and easy to identify programs
associated with r.support.Of course, I could just rewrite r.support to not use these all together
and just have one binary called r.support. That is probably the optimal
solution.
Actually, I'd rather go the other way, i.e. have separate user-visible
programs (i.e. r.support.*) for each category rather than forcing the
use of the r.support menu.
Supporting non-interactive use would be an added bonus (I've already
written r.region).
Let me know if you would prefer them go in $(ETC) or if I should
reorganize r.support as a single binary.
Rename them to r.support.* and put them in $(BIN).
--
Glynn Clements <glynn@gclements.plus.com>