Re: [pcre-dev] Replies to many, again

Góra strony
Delete this message
Autor: Daniel Richard G.
Data:  
Dla: pcre-dev
Stare tematy: Re: [pcre-dev] State of the SVN repository, Re: [pcre-dev] Building with Msys/MinGW on Windows (was Re: Replies to many), [pcre-dev] Here is pcre-7.1-RC3 for you to play with, Re: [pcre-dev] State of the SVN repository
Temat: Re: [pcre-dev] Replies to many, again
On Mon, 2007 Mar 26 13:04:09 -0400, Sheri wrote:
> >
> Hi Daniel,
>
> (sorry forgot to change the address to the group's on previous message)
>
> Here's a transcript:
>
> $ cd /usr
> $ ls
> Thumbs.db bin doc etc home m.ico mingw msys.bat msys.ico uninstall
> $ cd /lib/
> sh: cd: libs: No such file or directory


Sheri,

So MSYS binaries don't use any DLL libraries of their own? I'd figure there
might be ones for e.g. libiconv or libxml2.

(I was hoping to see what the naming convention was for these such DLLs---
"lib" prefix or no? Library version number or no?---to compare with what
Libtool is giving us in that environment.)


On Mon, 2007 Mar 26 16:44:07 +0100, Philip Hazel wrote:
>
> The following changes have happened since -RC2:
>
>  5. Changed the diff options in RunGrepTest from -u to -ub. On Linux, 
>     this makes it not show a difference between lines ending in LF and
>     CRLF. I'm hoping this might work in Windows too.


Careful, this will make "foo bar" and "foo bar" (one vs. two spaces in
between) look the same.

>  7. I renamed makevp-{compile,linklib}.txt as makevp-{c,l}.txt, as 
>     requested. 


>From Stefan:


    I renamed the list files to makevp_[cl].txt respectively and 
    changed makevp.bat accordingly. I decided against 
    -(linklib|compile) because this doesn't work in DOS and TLIB.EXE 
    had problems with the minus.


I believe that does need to be an underscore in the name.

> How close are we now? What now needs doing before a real 7.1 release? I
> have the following:
>
> . Cmake support: Daniel said he'd post some patches, but I haven't seen
> anything yet.


I'll send those in shortly after this message. For real this time :]


On Mon, 2007 Mar 26 10:17:37 +0100, Philip Hazel wrote:
> On Sun, 25 Mar 2007, Daniel Richard G. wrote:
>
> > * Need to either drop the LICENSE file, or replace it with a short "Please
> > see licensing terms in COPYING" message. Having two copies of the
> > software license is asking for trouble.
>
> I don't want to drop it - I don't think the name COPYING is one which
> obviously suggests "this is where to look for the licence" to somebody
> who comes to this fresh. Having the two files hasn't caused any trouble
> so far. :-) Personally, I'd be more inclined to have COPYING point to
> LICENCE than the other way round, if we have only one. Of course, there
> is also the LICENCE vs LICENSE issue...


Having COPYING pointing to LICENCE is fine; it's the redundancy of the
content that really needs to go away.

> > * All the files generated/added by the autogen bootstrap (configure,
> > install-sh, etc.) need to be removed, as those don't belong in a
> > versioned repository. Human-edited files only. (Standard MO is to pull
> > down the repository, and have autogen.sh generate everything needed.)
>
> Well, if I can figure out a complete list, I'll do that.


I believe these should be all of them:

    aclocal.m4
    configure
    missing
    install-sh
    config.h.in
    mkinstalldirs  (already removed)
    depcomp
    config.sub
    config.guess
    Makefile.in
    INSTALL  (generic version added by Automake)
    ltmain.sh


> > Also: Nigel mentioned that Exim has a commit script enforcing version-tag
> > properties---that would probably be good to have here as well. I'm less in
> > favor of enforcing no tabs, but something guarding against trailing
> > whitespace would be nice to throw in.
>
> Tabs are much more of a PITA than trailing spaces, IMO. I never use
> them. Well, unless I'm forced to by idiotic specifications such as that
> of Makefiles. I'm not the only person who thinks this. There is a nice
> description of what chaos they can cause here:
>
> http://mail.python.org/pipermail/python-list/2003-January/183758.html


Oh, I'm not opposed to bouncing out tabs---you should read "less in favor
of" merely as "less enthusiastic about." By all means, the source files
already haven't a single tab among them; may as well keep things that way.


On Mon, 2007 Mar 26 15:57:45 -0700, Craig Silverstein wrote:
>
> fwiw, at Google we include all the autogenerated files in the
> source-control system. That way, folks can still use them even if
> they don't have the right version of autotools installed.
>
> It's up to you, but I just wanted to point out that there are
> different approaches here.


I understand why this is done, but it comes down to abusing the SCM as an
one-stop distribution mechanism. Google is its own special case, of course,
but in most projects the proper approach is to generate regular snapshot
tarballs. (Which, I might point out, also helps those poor souls who don't
have the relevant SCM installed :-)


--Daniel


-- 
NAME   = Daniel Richard G.       ##  Remember, skunks       _\|/_  meef?
EMAIL1 = skunk@???        ##  don't smell bad---    (/o|o\) /
EMAIL2 = skunk@???      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)