|
From: Mark L. <la...@mi...> - 2003-06-04 04:09:40
|
I had an idea a while back where you would use the module command to generate Makefile settings, i.e ---------------------------------------------- # Makefile all: foo Makefile.settings: $MODULESHOME/modulecmd.tcl makefile load foo/1.2.3 bar/6.5.4 >$@ -include Makefile.settings ---------------------------------------------- but i gave up when it didn't seem to really solve the problem I didn't really have. Another idea: if you are modifying the Makefiles already, I would do something like CFLAGS += $(MOD_CFLAGS) LDFLAGS += $(MOD_LDFLAGS) and then in your modules, setenv MOD_CFLAGS "-I$mp/include" setenv MOD_LDFLAGS "-L$mp/lib -lfoo" So you would have to load the modules in your shell before running make. -Mark Mark Lakata, Staff Engineer 1225 Charleston Road voice 650-567-5170 MIPS Technologies Mountain View CA 94043 fax 650-567-5002 On Fri, 30 May 2003, Harlan Stenn wrote: > I am working on some configuration management tools for a modules > installation. > > I *think* I need to solve two problems. > > The first is "does X exist?", where X would be a module. This would be > mostly used for dependency stuff. I will have to address version issues > soon - phase 1 could be "does any version of X exist?", phase 2 could be > "does X/1.2.3 exist?", and phase 3 could be "Do we have version 1.2.3 or > later of X"? > > I think that I can solve all of these cases with something that says "give > me the list of all versions of X that we know about." An empty list imples > that we don't have X installed at all. It's then up to some other layer to > implement the selection criteria (phases 1-3) described above. > > The 2nd problem has to do with getting paths. > > Sometimes while building software one needs a particular version of a tool. > It may not be possible to simply prepend a module containing this tool to > the PATH; indeed, we don't *know* if that tool's modulefile will prepend or > append to the PATH, or how it will affect any other part of the environment. > > One can have a "nest" of disparate dependencies. > > So we may need an explicit path to the tool so we can use it during the > build. > > Related to this problem is the issue of libraries and #include paths. > > I'm thinking that the baby step toward understanding this issue better (and > making some progress) would be to have a way to get the path to the "top" of > the installation area for a particular module, and from there one could: > > mp=`module path foo/1.2.3` > > and: > > CFLAGS+= -I$mp/include > LDFLAGS+= -L$mp/lib > PROG_FOO= $mp/bin/foo > > Thoughts or ideas please? > > H > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Modules-interest mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modules-interest > |
