On Fri, 2011-10-07 at 13:28 -0700, Jeremy Huddleston wrote: > >> On Oct 6, 2011, at 1:09 PM, Gaetan Nadon wrote: > >>> The srcipt runs 'make dist' to create the tarball. We don't have to prompt > >>> the user for the tar name, the version number or the section name. > >> > >> Should we 'make distcheck' instead? > > > > Excellent question. I have considered that. My reasons were not very > > strong: > > ... > > Let's see how it goes with other. I have never tried it. I am not really > > against it. It could be optional too. > > Yeah, your reasons above are valid. How about a --distcheck option to toggle > on this behavior?
Done. > > > > > >> > >>> Interface > >>> --------- > >>> Usage: publish.sh [options] section[/module]... > >>> > >>> Section: > >>> app|data|doc|driver|font|lib|mesa|proto|util|xcb| > >>> xkeyboard-config|xserver > >> > >> I would prefer passing in paths to my local git checkouts over > >> section/module. > >> You should still be able to do the same -<version> foo by checking if the > >> argument > >> is a dir, if not, chop off the -* and check again. > > > > Sorry I don't get it. Can you give me an example? > > $ git clone ssh://git.freedesktop.org/git/xorg/app/xedit > $ git clone ssh://git.freedesktop.org/git/xorg/lib/libX11 > > do some stuff in both > > publish.sh libX11 xedit > > or > > publish.sh libX11-1.10.0 libX11-1.9.4 libX11-1.8.8 xedit > > > An entry such as lib/private_libX11 will work. I just need "lib" to get > > the section and there should be > > either no subdir or only one subdir. I am basically following the module > > url: > > > > git://anongit.freedesktop.org/xorg/ ==> lib/libX11 > > or git://anongit.freedesktop.org/xorg/ ==> xserver > > > > What would be the structure of your "local git checkouts"? > > As above. I just dump them all into one directory. I rename font/util to > font-util and util/macros to util-macros to avoid confusion. I also have > multiple xserver-*/ dirs at common checkouts to avoid rebuilding when going > between versions. > > > Also keep in mind the section[/module] is a format used by build.sh and > > it follows the module url > > You can get the module URL from git, so I don't think it's necessary to > mirror that layout on the FS. Done. > > >> Why are we duplicating code between release.sh and publish.sh? > > > > That is something to decide. I aimed to have publish.sh be a superset of > > release.sh in order to have only a single release script. > > > >> Can we instead have publish.sh be a smart wrapper around release.sh. > > > > I used release.sh as a functional spec and used some of the code. > > Calling a script within a script introduces multiple points of failure > > and a lot of additional tests. The odds of a change done in release.sh > > and be tested from publish.sh are next to nil. > > Returning information, sharing variables, error checking, user messages > > style and consistency are all more difficult. > > With the assumption that we have a single script (need to revamp the > > wiki), the internal implementation does not matter much, so as long as > > it is maintainable. > > > > I also copied the structure of build.sh (which early on I thought I > > could call). The only script being called is update_moduleset.sh which > > has already given trouble with the readlink issue (still to be solved). > > Ok, if this is the case, I'd like to see this new script replace release.sh > so we don't have duplicated functionality. It seems like this should be able > to completely replace release.sh with some minor tweaks (like this following > one). Done. > > >> Alan also sent out a release.sh patch (which I reviewed and provided a > >> followup for) > >> which does some of the same "intelligent" aspects but for the current > >> module. > >> I would like to either see both of these exist together or update > >> publish.sh to support "." Done. It can also be given any valid path, absolute or relative to the script invocation directory. > > > > The thought had crossed my mind, given the existing working habits. I > > was waiting for comments on that. > > I don't have any objection. > > Thanks, > Jeremy >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
