So you're (always?) getting tarballs without any doc/doxygen-doc subdirectories? Does "make dist" say that it's copying the doxygen-doc subdirectory? Any idea who's removing it later?
I managed to get such a tarball without doc only once, but it disappeared after I added some debug commands to config/distscript.sh to see where doc/doxygen-doc was being deleted. Strange. Brice Le 07/04/2014 22:05, Jeff Squyres (jsquyres) a écrit : > Right -- I've done that (i.e., if I do "make doc" again, it does nothing > because it's already done). And "make dist" works fine. > > But "make distcheck" fails when it runs "make dist" in the subdir of the > expanded tarball fails because doc/doxygen-doc doesn't exist in there. > > > On Apr 7, 2014, at 3:57 PM, Brice Goglin <brice.gog...@inria.fr> wrote: > >> In v1.9+, you need make doc before make dist or make distcheck. It may >> explain your problem? >> I changed this a couple weeks ago to make things much easier to >> understand/maintain (but a little bit harder to use :)) >> >> Brice >> >> >> Le 07/04/2014 21:37, Jeff Squyres (jsquyres) a écrit : >>> I just pushed 143e27248f928797e2e8532747386c67c9f8d873, which converted >>> distscript.csh to distscript.sh. >>> >>> If it works well on master, we can pull it to the v1.9 branch. >>> >>> I notice that "make distcheck" is broken, however -- when it goes to "make >>> dist" in the expanded tarball, I get the following message: >>> >>> ----- >>> *** The srcdir does not already have a doxygen-doc tree built. >>> *** hwloc's config/distscript.csh requires the docs to be built >>> *** in the srcdir before executing 'make dist'. >>> make[3]: *** [dist-hook] Error 1 >>> make[2]: *** [distdir] Error 2 >>> make[1]: *** [dist] Error 2 >>> make: *** [distcheck] Error 1 >>> ----- >>> >>> Is this expected / has this been broken for a while? >>> >>> >>> >>> >>> On Mar 31, 2014, at 1:42 AM, Brice Goglin <brice.gog...@inria.fr> wrote: >>> >>>> Le 31/03/2014 00:57, Christopher Samuel a écrit : >>>>> On 30/03/14 02:04, Ralph Castain wrote: >>>>> >>>>>> turns out that some linux distro's automatically set LS_COLORS in >>>>>> your environment when running old versions of csh/tcsh via their >>>>>> default dot files >>>>> For example RHEL6 does this.. >>>> Looks like it's a 10 years old conflict between csh and coreutils. It's >>>> crary hwloc has to work around this very old issue, we should just stop >>>> using csh and distros that haven't fixed this :) >>>> >>>> Brice >>>> >>>> _______________________________________________ >>>> hwloc-devel mailing list >>>> hwloc-de...@open-mpi.org >>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel >> _______________________________________________ >> hwloc-devel mailing list >> hwloc-de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel >
