v8: fix dragonflybsd build

fix dragonflybsd build

[bnoordhuis1, 2012-11-20 21:42:56]

v8: fix dragonflybsd build

* fix gyp build
* don't require libexecinfo, it's not there
* libpthread doesn't implement sem_timedwait(), fall back to sem_wait()

DragonFlyBSD is a mostly compatible fork of FreeBSD. This commit papers over the
remaining differences.

[sjg2, 2013-01-02 04:46:38]

libexecinfo is in pkgsrc wip and builds fine from there.

sem_timedwait() has been added (unmasked) since you submitted this patch in
DragonFly master.

[Sven Panne, 2013-01-02 08:06:46]

https://codereview.chromium.org/11421013/diff/1/src/platform-freebsd.cc
File src/platform-freebsd.cc (right):

https://codereview.chromium.org/11421013/diff/1/src/platform-freebsd.cc#newco...
src/platform-freebsd.cc:51: #if !defined(__DragonFly__)
One general comment about such #ifs: Instead of scattering obscure platform
#ifdefs all over the place, please use feature-based #ifdefs and #define the
corresponding preprocessor symbol at a single central place. In our concrete
example:

Use

   #ifdef HAVE_EXECINFO_H
   #include <execinfo.h>
   #endif

here and similar conditionals in the changes below. Make sure that
HAVE_EXECINFO_H is defined where it is available, e.g. via our GYP files.

Doing it this way has the advantage that the code is much, much easier to read
an maintain. I know that the current v8 code is guilty of doing this massively
wrong already, but we shouldn't make it worse... :-)

[evilsjg, 2013-01-22 02:51:35]

http://www.thesjg.com/dragonfly/v8df.patch

Here's the patch I have used to build v8 locally, with libexecinfo from pkgsrc
wip and with the unmasked sem_timedwait()

[Sven Panne, 2013-05-15 12:31:52]

On 2013/01/22 02:51:35, evilsjg wrote:
> http://www.thesjg.com/dragonfly/v8df.patch
> 
> Here's the patch I have used to build v8 locally, with libexecinfo from pkgsrc
> wip and with the unmasked sem_timedwait()

I'm just going through my list of old CLs and hit this one: If I understand this
correctly, installing and additional package will take care of the missing
backtrace functionality. The rest of the change is basically saying
"dragonflybsd" is a BSD, too.

But what about sem_timedwait? The initial patch claims that it's not there,
while there the later patch seems to work *with* it. Can somebody clarify what's
going on? I'd like to land this in some form or close it, but first it would be
good to know the details.

[Sven Panne, 2013-05-15 12:32:22]

Removed Michael, added Jakob, just for fun. :-)

[Jakob Kummerow, 2013-05-15 12:55:46]

What I don't like about this patch in its current form is the inconsistency it
introduces to the various OS-based conditions in the .gyp files. We should
settle for either of:
(1) OS=="a" or OS=="b" or...
(2) OS!="win"
(3) OS in "a b ...".split()
(4) OS in ["a", "b", ...]
and then use that consistently. Moving some of these lists to global variables
would be very nice too, but a little messy in practice due to subtle differences
(sometimes we test for "Linux or *BSD or Mac", sometimes for "Linux or *BSD",
sometimes what we really mean is "do we compile with GCC", and so on).

[Sven Panne, 2013-05-15 13:31:21]

On 2013/05/15 12:55:46, Jakob wrote:
> [...] Moving some of these lists to global variables
> would be very nice too, but a little messy in practice due to subtle
differences
> (sometimes we test for "Linux or *BSD or Mac", sometimes for "Linux or *BSD",
> sometimes what we really mean is "do we compile with GCC", and so on).

I think we should slowly move towards a feature-based approach in our
build-system, too, e.g. define a variable IS_POSIX_LIKE based on 'OS in ["blah",
"bloh", ...]' and use that to include platform_posix.cc in the build. Similarly
we could handle other features like "no strict aliasing, please", "supports
execinfo" etc.

But you are right, as a first step using one of (1)..(4) consistently makes
sense. I would opt for (4). (1) too repetitive, instead of (2) I would prefer
positive formulations, and (3) won't work for platforms with whitespace in its
name (*very* common, but nevertheless ;-)

[Benedikt Meurer, 2013-09-23 08:09:13]

Can you rebase this one on bleeding_edge?