On Apr 7, 2014, at 5:05 PM, Brice Goglin <brice.gog...@inria.fr> wrote:
> So you just broke my make dist :/ Really? Doh! :-( > I don't have MacOS to test things. If rsync or tar or whatever can > dereference symlinks, that'll work for me. Ok, lemme look at tar -- there's a canonical way to copy dir trees with tar; let me look it up... > > commit 0ebeff689e9414d5eedbf53e7c8697a3af5e4b72 > Author: Brice Goglin <brice.gog...@inria.fr> > Date: Fri Mar 21 18:51:14 2014 +0100 > > dist: fix support for doc/doxygen-doc being a symlink > > make dist works when building out-of-source if $srcdir/doc/doxygen-doc > is a symlink to builddir/doc/doxygen-doc. > But it actually fails to copy the doxygen-doc tree because it > doesn't dereference the symlink. Fix that. > > Brice > > > > > Le 07/04/2014 22:59, Jeff Squyres (jsquyres) a écrit : >> On Apr 7, 2014, at 4:33 PM, Brice Goglin <brice.gog...@inria.fr> wrote: >> >>> So you're (always?) getting tarballs without any doc/doxygen-doc >>> subdirectories? >> That's correct -- doc/doxygen-doc is in the source tree, but does not end up >> in the tarball. >> >>> Does "make dist" say that it's copying the doxygen-doc >>> subdirectory? Any idea who's removing it later? >> Mmm... good point... >> >> /me investigates >> >> Ah, I see the issue. On OS X, this: >> >> doit cp -rpf $srcdir/doc/doxygen-doc/ $distdir/doc >> >> Does not actually copy the doxygen-doc directory to $distdir. If I remove >> the trailing slash, it works: >> >> doit cp -rpf $srcdir/doc/doxygen-doc $distdir/doc >> >> (i.e., doxygen-doc ends up in $distdir and distcheck works properly) >> >> There's probably a reason for this, but I'm not too interested in tracking >> it down. I just removed the trailing slash... >> >> I note that the OS X man page for cp says: >> >> Historic versions of the cp utility had a -r option. This implementation >> supports that option; however, its use is strongly discouraged, as it >> does not correctly copy special files, symbolic links, or fifo's. >> >> Instead, the OS X cp supports -R (Linux cp does, too). >> >> I guess we should be using something better than cp -r to copy the directory >> over -- perhaps tar? >> >>> 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 >>> _______________________________________________ >>> 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 -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
