Trouble compiling prboom+ on Windows: PCRE3 library

[Albertoni]

I can't find an "just download and unzip" version of pcre3.lib and pcreposix3.lib for Windows, like the SDL dependencies had.

 

So what exactly do I need to compile to get those files? I see http://pcre.org/ seems to be the code for what I need, but I'm wondering if there's an easier way.

[Graf Zahl]

For Windows follow this link:

 

http://gnuwin32.sourceforge.net/packages/pcre.htm

 

You will need these downloads:

 

http://gnuwin32.sourceforge.net/downlinks/pcre-bin-zip.php

http://gnuwin32.sourceforge.net/downlinks/pcre-lib-zip.php

 

Been there, done that just a few days ago. I really have to question the use of such obscure libraries without providing some actual info where to get them.

 

[Albertoni]

Thanks!

 

I imagine you'll be pleased to know that so far, even when running through the MAPINFO code, demo compatibility is maintained; At least for kb1's TASs.

[Graf Zahl]

I made damn well sure that the new code only gets executed when the map actually has a MAPINFO. The finale code, for example was so messy that I rather chose to create duplicates to avoid risking problems.

 

I think there's two things left: Episode menu integration and boss deaths, both of which are far less of a demo compatibility issue than these intermission screens whose timing is strictly off limits for change.

 

[kb1]

3 hours ago, Graf Zahl said:

For Windows follow this link:

 

http://gnuwin32.sourceforge.net/packages/pcre.htm

 

You will need these downloads:

 

http://gnuwin32.sourceforge.net/downlinks/pcre-bin-zip.php

http://gnuwin32.sourceforge.net/downlinks/pcre-lib-zip.php

 

Been there, done that just a few days ago. I really have to question the use of such obscure libraries without providing some actual info where to get them.

 

Thanks so much for this - I hit the same brick wall. This is helpful. This is used to regular expressions against demo filenames, for the automatic setting of complevel, right?

 

2 hours ago, Albertoni said:

Thanks!

 

I imagine you'll be pleased to know that so far, even when running through the MAPINFO code, demo compatibility is maintained; At least for kb1's TASs.

Did you write a parser to read that data I posted, and replace the hard-coded values with variables populated from the parser? If so, very cool! When I made that, the goal was to simply get hard-coded values out of the executable, into a lump. This is Priority #1 for upping the port standard: The removable of hard-coded values from the exe.

[Albertoni]

2 hours ago, kb1 said:

Did you write a parser to read that data I posted, and replace the hard-coded values with variables populated from the parser?

No, I have no parser yet. I'm just using hard-coded values in the same data structures MAPINFO will need. I can make map01 go to map20 and a demo recorded like that works afterwards.

[grommile]

On 21/04/2017 at 8:20 PM, Graf Zahl said:

Been there, done that just a few days ago. I really have to question the use of such obscure libraries without providing some actual info where to get them.

This is an expectations-mismatch issue.

 

To a Windows person, libpcre is obscure.

 

To a Linux person, libpcre is a critical system component, without which you can't get any work done.

[dpJudas]

I'm not sure a regular expression library qualifies as a critical system component on Linux.

[Graf Zahl]

On Linux a lot of obscure stuff appears to be essential. Do I have to mention Autotools...? :D:D:D

 

[grommile]

12 hours ago, dpJudas said:

I'm not sure a regular expression library qualifies as a critical system component on Linux.

Let me remove your uncertainty:

 

Spoiler

mormegil@cocytus:~$ ldd /bin/grep # this shows what libraries the 'grep' regular-expression text search tool is linked against
    linux-vdso.so.1 (0x00007ffc25768000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb33589b000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb335697000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb3352eb000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb3350ce000)
    /lib64/ld-linux-x86-64.so.2 (0x0000562450976000)
mormegil@cocytus:~$ apt show grep # this shows the package metadata for the 'grep' package

Package: grep
Version: 2.20-4.1
Essential: yes
Installed-Size: 1,303 kB
Maintainer: Anibal Monsalve Salazar <anibal@debian.org>
Provides: rgrep
Depends: dpkg (>= 1.15.4) | install-info
Pre-Depends: libc6 (>= 2.14), libpcre3 (>= 1:8.35)
Conflicts: rgrep
Homepage: http://www.gnu.org/software/grep/
Tag: implemented-in::c, interface::commandline, role::program,
 scope::utility, suite::gnu, use::searching, works-with::text
Section: utils
Priority: required
Download-Size: 325 kB
APT-Manual-Installed: yes
APT-Sources: http://httpredir.debian.org/debian/ jessie/main amd64 Packages
Description: GNU grep, egrep and fgrep
 'grep' is a utility to search for text in files; it can be used from the
 command line or in scripts.  Even if you don't want to use it, other packages
 on your system probably will.
 .
 The GNU family of grep utilities may be the "fastest grep in the west".
 GNU grep is based on a fast lazy-state deterministic matcher (about
 twice as fast as stock Unix egrep) hybridized with a Boyer-Moore-Gosper
 search for a fixed string that eliminates impossible text from being
 considered by the full regexp matcher without necessarily having to
 look at every character. The result is typically many times faster
 than Unix grep or egrep. (Regular expressions containing backreferencing
 will run more slowly, however.)

 

In Debian, 'Essential: yes' means "this package is a sufficiently critical system component that all packages which aren't Essential: yes are allowed to assume it has been installed". grep, as shown, is Essential: yes and depends on libpcre3, so... yes, libpcre3 is a critical system component. (The C header files won't be automatically installed, but installing them is a simple matter of saying 'apt-get install libpcre3-dev'.)

 

12 hours ago, Graf Zahl said:

On Linux a lot of obscure stuff appears to be essential. Do I have to mention Autotools...? :D:D:D

 

Linux is the Unix-like platform on which it is easiest to get rid of fucking Autotools, because you don't need to care about backwards compatibility with 742 subtly different flavours of antediluvian steam-driven proprietary commercial Unix :D :D :D

 

(Lots of people still use it because, y'know, people get set in their ways, but nobody likes it except possibly Saint Richard.)

[Graf Zahl]

2 minutes ago, grommile said:

Linux is the Unix-like platform on which it is easiest to get rid of fucking Autotools, because you don't need to care about backwards compatibility with 742 subtly different flavours of antediluvian steam-driven proprietary commercial Unix :D :D :D

 

(Lots of people still use it because, y'know, people get set in their ways, but nobody likes it except possibly Saint Richard.)

 

It won't disappear if some people - even here on Doomworld -  argue that it is implicitly expected SOP for compiling software un Linux (there was this discussion some time ago in the Chocolate-Doom thread.)

 

My personal hatred for it comes from the fact that I have never managed to sort out an Autotools project when being tasked with integrating its source into something larger. This thing seems to instill some utterly inane conventions that makes it impossible to use the code in another context and the project files seem to lack any sort of coherence and introduce an insane amount of clutter into the project. Bad news if no alternative is provided.

 

[grommile]

The complication with getting Unixy people to stop using Autotools is that - as usual where such matters are concerned - even though lots of Unixy people agree that it's fucking awful, there are numerous strongly-held and mutually incompatible opinions about what the replacement should be:

• Some people replace it with a hand-rolled Perl script and a Makefile specifically written for use GNU Make, since they don't care about Visual Studio users and everyone in the Unix (or Cygwin/MinGW) world has Perl and either has, or can more or less trivially obtain, GNU Make.
• Some people replace it with CMake (which might actually finally be winning the Autotools Succession War that has been smouldering for an alarming number of years).
• Some people replace it with waf (despite its architecture making Autotools + Make look sane).
• Some people replace it with SCons (which may well be fading from view).
• A few people replace it with redo.
• Some people replace it with something insane of their own devising.
• Some people replace it with the specialist toolchain for the GUI library they're using.
• Some people write their programs in a language that has its own building-and-packaging toolchain specifically designed for programs in that language.
• Some people refuse to replace it because get off my goddamn lawn.
• Some people refuse to replace it because Autotools has the notable virtue that if all you want to do is build and install the packaged upstream source code of a program you don't actually need to have autotools installed; you can just invoke the 'configure' script shipped with the packaged source code.

 

(Strictly speaking, the expected SOP is that if someone grabs the packaged upstream source, your build sequence can be invoked as if your software used autotools i.e. "./configure && make && sudo make install" should configure the software to build on your system, build it on your system, and install it into /usr/local .)

[dpJudas]

5 hours ago, grommile said:

Let me remove your uncertainty:

 

In Debian, 'Essential: yes' means "this package is a sufficiently critical system component that all packages which aren't Essential: yes are allowed to assume it has been installed". grep, as shown, is Essential: yes and depends on libpcre3, so... yes, libpcre3 is a critical system component. (The C header files won't be automatically installed, but installing them is a simple matter of saying 'apt-get install libpcre3-dev'.)

Well, the problem with this is that libpcre3 is not marked as essential:

mbn@esoteric:~$ apt show libpcre3|grep -i essential
mbn@esoteric:~$ apt show grep|grep -i essential
Essential: yes
mbn@esoteric:~$

In other words, grep using libpcre3 is an implementation detail of grep. A third party application can't assume this remains true, it must add a direct dependency on the libpcre3 package.

[Lavender Moon]

On 4/21/2017 at 6:22 PM, kb1 said:

Thanks so much for this - I hit the same brick wall. This is helpful. This is used to regular expressions against demo filenames, for the automatic setting of complevel, right?

I was going to say "no, I managed to compile just fine without it", but then I checked and found out that it actually is used for that purpose. Which makes it even weirder that there's a HAVE_LIBPCREPOSIX define that isn't always honored. Well, that makes me glad I hadn't gotten around to hacking any references to it out of my port yet. Makes me less glad I threw away the version of the codebase where I had readded PCREPOSIX, but live and learn.