Hi everyone.
Sorry that I've been away for the past few days; other fires have been
keeping me busy :]
A few messages from the past few days that I'd like to touch on...
On Sat, 2007 Mar 17 10:33:15 +0100, Stefan Weber wrote:
> Good morning everyone,
>
> 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.
Juxtapose that with this next bit...
On Tue, 2007 Mar 20 12:17:26 +0000, Philip Hazel wrote:
>
> 7. Renamed !compile.txt and !linklib.txt as makevp-compile and
> makevp-linklib and modified makevp.bat appropriately.
Philip, the files currently in SVN reflect the problematic names. Could you
put in Stefan's change?
> 9. Re-jigged the way the character tables are done, following discussion
> here. There is now a distributed file called pcre_chartables.c.dist,
> which is a set of ASCII tables. By default, this is copied to
> pcre_chartables.c at "make" time. However, if --enable-rebuild-chartables
> is used with "configure", the previous method is used: dftables.c is
> compiled and run in order to create pcre_chartables.c.
This is a good approach.
> . Check with Daniel on the Cmake support - how much needs doing there?
I've fleshed it out, but it's not entirely working yet. I'll send in what I
have now in a separate message.
On Tue, 2007 Mar 20 11:31:51 -0400, Bob Rossi wrote:
>
> It appears that the cp command in the Makefile,
> pcre_chartables.c: pcre_chartables.c.dist
> cp pcre_chartables.c.dist pcre_chartables.c
> should be,
> pcre_chartables.c: $(top_srcdir)/pcre_chartables.c.dist
> cp $(top_srcdir)/pcre_chartables.c.dist pcre_chartables.c
> with that change it works properly.
>
> Is that the proper change? I just realized that I also have this problem
> with mingw, it's just that when you do an in tree build you don't see
> it. It only becomes obvious when out of tree builds are done.
Yes, the .dist file has to be explicitly referenced off the source
directory. But you'd normally use $(srcdir) instead of $(top_srcdir), as
source and destination are in the same place in the tree.
On Tue, 2007 Mar 20 16:50:32 -0700, Craig Silverstein wrote:
> } should be,
> } pcre_chartables.c: $(top_srcdir)/pcre_chartables.c.dist
> } cp $(top_srcdir)/pcre_chartables.c.dist pcre_chartables.c
> } with that change it works properly.
>
> Seems likely to me. You could also do
> pcre_chartables.c: $(top_srcdir)/pcre_chartables.c.dist
> cp $< $@
>
> since I think previous discussion indicated $< and $@ are safe for all
> versions of make. :-)
$@ is safe, but $< is meant for use in suffix rules (e.g. ".c.o:"). Only
GNU Make supports $< in explicit rules; most other make(1) programs will
evaluate it to empty.
> Also, you may want to use 'cp -f'. I don't know what will happen on
> all systems, if pcre_chartables.c already exists.
Even better is to "rm -f" the file beforehand, and use $(LN_S) to just
symlink it :-) (AC_PROG_LN_S will make it a copy operation on less
enlightened filesystems.)
> Philip: one thing you can do to test for stuff like this is to run
> 'make distcheck' before distributing. This does various things to
> make sure the distribution ('make dist' output) is sane.
I agree, but I would phrase this a bit more strongly: "make distcheck" (and
not "make dist") is the mechanism by which the official distribution
tarball should be generated.
(Note that the operations performed by "distcheck" are a strict superset of
"dist", so it also gives you the tarballs, but only "distcheck" actually
ensures they are correct as far as Autotools is concerned.)
On Wed, 2007 Mar 21 10:24:04 -0400, Sheri wrote:
>
> BTW, the dll libraries get different names out of 7.2 RC2 than 7.0 and
> 6.7 (configured in msys). I am accustomed to seeing "pcre.dll" and
> "pcreposix.dll". With 7.2 RC2 I am getting libpcre-0.dll and
> libpcreposix-0.dll. Our application is linked to pcre.dll. I tried
> renaming libpcre-0.dll to pcre.dll, and then our application complained
> that it couldn't find pcreposix.dll. Our app didn't previously need a
> separate pcreposix.dll (some of our older services use the posix api,
> but previously everything was available in the pcre.dll which got
> produced in the older configuration process). Renaming
> libpcreposix-0.dll to pcreposix.dll and putting that on the same path
> doesn't resolve the issue. I think pcreposix.dll is looking for
> libpcre-0.dll.
Yes, the libraries have dependency library names embedded into them.
Renaming only works for a top-level dependency.
The new names come to us from Libtool. See next message...
On Wed, 2007 Mar 21 11:46:37 -0400, Sheri wrote:
> >
> Yes I hope so. Also have another issue. I was previously able (when
> making pcre 6.7 and 7.0) to include a .coff file (produced with windres
> from a pcre.rc file I created) in Makefile.in so that the pcre.dll file
> contained version and copyright info. Linking with the .coff file makes
> the dll library display version info when mouse-hovered in Windows
> explorer, and show more detailed info in file properties.
Sounds like a nice touch...
> # Some Windows-specific targets for MinGW. Do not use for Cygwin.
>
> winshared : .libs/@WIN_PREFIX@??? .libs/@WIN_PREFIX@??? \
> .libs/@WIN_PREFIX@???
>
> .libs/@WIN_PREFIX@??? : libpcre.la
> $(CC) $(CFLAGS) -shared -o $@ pcre.coff\
> -Wl,--whole-archive .libs/libpcre.a \
> -Wl,--out-implib,.libs/libpcre.dll.a \
[...]
I'm thinking that all this---the rules to create e.g. pcre.dll, and the
.coff metadata---should be addressed by the CMake side of things. They're a
bit of a third wheel in Makefile.am, and MinGW can be considered a special
case of a "Windows build environment."
This way, on MinGW, ./configure gets you Unixy-style MinGW libraries
(libpcre-0.dll et al.), and CMake gets you more Windowsy-style ones
(pcre.dll + Explorer properties).
On Wed, 2007 Mar 21 13:00:39 -0400, Sheri wrote:
>
> I start with an .rc file which I concocted from something I saw online.
> I run my rc through windres (in the Msys shell) to make a compatible rc
> file:
>
> $ windres slppcre.rc pcre.rc
>
> Then I make the coff file like this:
>
> $ cd pcre-7.0
> $ windres ../pcre.rc pcre.coff
Are pcre.rc and pcre.coff binary files?
> This what my original slppcre.rc file looks like:
>
> 1 VERSIONINFO
> FILEVERSION 7, 0, 0, 0
> PRODUCTVERSION 0, 0, 0, 0
> FILEFLAGSMASK 0
> FILEOS 0x40000
> FILETYPE 1
> {
> BLOCK "StringFileInfo"
> {
> BLOCK "040904E4"
> {
> VALUE "FileDescription", "pcre w utf8 ucp no-stack newline-any"
> VALUE "LegalCopyright", "refer to license"
> VALUE "FileVersion", "use with PowerPro plugins"
> VALUE "License", "PCRE is a library of functions to support regular
> (truncating because email is going to add linebreaks...)"
> VALUE "WWW", "http://www.pcre.org"
> }
> }
> }
Interesting. The contents are going to need some review, but this looks
like a reasonable thing to have in there.
> I would be happy to zip up slppcre.rc, pcre.rc and pcre.coff if anyone
> want them. We could update the file version and use a generic
> FileDescription so a coff file could be included with the pcre distro. I
> think for the CMake process, the original rc could be utilized.
Please do send in whichever of those files are plain text. This is
something we'll want to have in, eventually.
--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)
