Well, i think the easiest way to solve this gpde issue to move the N_pde.h header file into grass6/include. So there should be no need to copy it. I have kept the header file in the source directory for the doxygen documentation generation. To have all the used structures documented. But i guess i can tell doxygen to use ../../include/N_pde.h instead of keeping the header file in the source dir.
Soeren 2007/10/18, Glynn Clements <[EMAIL PROTECTED]>: > > > Maciej Sieczka wrote: > > > Glynn Clements wrote: > > > Maciej Sieczka wrote: > > > > > >>>> sorry but I'm not an make guru and thus see it simple: if I run > comand > > >>>> "make -j4" it should get along with it or fail with "err blah > parallel > > >>>> buld not supported". Current CVS version does neither of it. > > >>> I hope we don't give up so early. Probably just a few Makefiles > > >>> need to be fixed (basically, get the target order right therein). > > >>>> As multicore CPU's are getting more popular, more and more users > will be > > >>>> trying to run "make -j X" and thus report failure as bug [1]. > > >>> Not always. As written yesterday, "make -j3" worked for me on my > RHEL5 > > >>> box. Now testing with Mandriva. > > >>>> If I can help with testing, drop me instructions. I have Gentoo > ~x86 > > >>>> system (gcc version 4.2.1; GNU Make 3.81). > > >>> Please help testing. Just run it and see if and where it fails. > > >>> Then check the problematic Makefile(s) for correct order: > > >>> http://grass.gdf-hannover.de/wiki/Development#GRASS_Makefile_writing > > >> As for testing: I get the following errors with make -j3 on > > >> Intel Core 2 6600 running 2.6.15-29-amd64-xeon (Ubuntu Dapper): > > >> > > >> -- > > >> Errors in: > > >> /home/maciek/src/straight/grass63/lib/gpde > > >> /home/maciek/src/straight/grass63/imagery/i.vpoints > > >> /home/maciek/src/straight/grass63/misc/m.cogo > > >> /home/maciek/src/straight/grass63/raster/r.gwflow > > >> /home/maciek/src/straight/grass63/raster/r.to.rast3elev > > >> /home/maciek/src/straight/grass63/raster3d/r3.gwflow > > >> /home/maciek/src/straight/grass63/vector/v.sample > > > > > > What errors, exactly? > > > > That's all it says: > > > > Started compilation: Thu Oct 18 00:07:37 CEST 2007 > > -- > > Errors in: > > /home/maciek/src/straight/grass63/lib/gpde > > /home/maciek/src/straight/grass63/misc/m.cogo > > /home/maciek/src/straight/grass63/raster/r.gwflow > > /home/maciek/src/straight/grass63/raster3d/r3.gwflow > > -- > > In case of errors please change into the directory with > > error and run 'make'. If you get multiple errors, you need > > to deal with them in the order they appear in the error log. > > If you get an error building a library, you will also get > > errors from anything which uses the library. > > -- > > Finished compilation: Thu Oct 18 00:11:12 CEST 2007 > > make: *** [default] Error 1 > > > > If you'd like to see full make and configure output they are > > here [1]. > > The relevant make output is necessary. > > lib/gpde: > N_arrays.c:19:25: error: grass/N_pde.h: No such file or directory > > I've just figured out what's going on; it's the way that phony targets > are being used. E.g. lib/gpde/Makefile has: > > default: headers lib > > headers: > for file in ./N_*.h ; do $(INSTALL_DATA) $$file > $(GISBASE)/include/grass/ ; done > > lib: headers > > "headers" is a prerequisite of "lib", and so will be built before it. > But "lib" is defined in Lib.make as: > > lib: $(GRASS_LIBRARY_TYPE) > > $(GRASS_LIBRARY_TYPE) is either "shlib" or "stlib". Assuming "shlib", > that's defined in Shlib.make as: > > shlib: $(SHLIB) > > When there are multiple rules for a given target, all of the > dependencies are merged, so in effect we have: > > lib: headers $(SHLIB) > > IOW, the headers target and the actual shared library are built in > parallel. > > Using phony targets for real files (as opposed to e.g. "clean") sucks. > > What we really want is a dependency like: > > $(SHLIB): headers > > But it isn't clear how to abstract out the library type. Note that: > > $(GRASS_LIBRARY_TYPE): headers > > won't work, as that just gives e.g.: > > shlib: headers > > shlib: $(SHLIB) > > which is equivalent to: > > shlib: headers $(SHLIB) > > which will still result in headers and $(SHLIB) being built in > parallel. > > Note to self (and anyone else who it concerns): a dependency such as > "foo: bar" does *not* make "foo" into an alias for "bar". Sure, making > foo will make bar, but if foo has other prerequisites, they will be > made in parallel with bar, not before it. > > Ugh. I don't immediately know how to solve this, but I do at least > know what's going on now. I'm fairly sure that that this is the cause > of many of the outstanding problems with parallel builds. > > -- > Glynn Clements <[EMAIL PROTECTED]> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev >
_______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
