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