Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] GIT: hwloc branch master updated. 0e6fe307c10d47efee3fb95c50aee9c0f01bc8ec
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2014-04-07 17:05:31


So you just broke my make dist :/
I don't have MacOS to test things. If rsync or tar or whatever can
dereference symlinks, that'll work for me.

commit 0ebeff689e9414d5eedbf53e7c8697a3af5e4b72
Author: Brice Goglin <Brice.Goglin_at_[hidden]>
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.Goglin_at_[hidden]> 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.Goglin_at_[hidden]> 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.Goglin_at_[hidden]> 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-devel_at_[hidden]
>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>>>> _______________________________________________
>>>> hwloc-devel mailing list
>>>> hwloc-devel_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> _______________________________________________
>> hwloc-devel mailing list
>> hwloc-devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>