[#15359] Timeout::Error — Jeremy Thurgood <jerith@...>

Good day,

41 messages 2008/02/05
[#15366] Re: Timeout::Error — Eric Hodel <drbrain@...7.net> 2008/02/06

On Feb 5, 2008, at 06:20 AM, Jeremy Thurgood wrote:

[#15370] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Eric Hodel wrote:

[#15373] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15374] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Nobuyoshi Nakada wrote:

[#15412] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15413] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/07

Nobuyoshi Nakada wrote:

[#15414] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15360] reopen: can't change access mode from "w+" to "w"? — Sam Ruby <rubys@...>

I ran 'rake test' on test/spec [1], using

16 messages 2008/02/05
[#15369] Re: reopen: can't change access mode from "w+" to "w"? — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15389] STDIN encoding differs from default source file encoding — Dave Thomas <dave@...>

This seems strange:

21 messages 2008/02/06
[#15392] Re: STDIN encoding differs from default source file encoding — Yukihiro Matsumoto <matz@...> 2008/02/06

Hi,

[#15481] very bad character performance on ruby1.9 — "Eric Mahurin" <eric.mahurin@...>

I'd like to bring up the issue of how characters are represented in

16 messages 2008/02/10

[#15528] Test::Unit maintainer — Kouhei Sutou <kou@...>

Hi Nathaniel, Ryan,

22 messages 2008/02/13

[#15551] Proc#curry — ts <decoux@...>

21 messages 2008/02/14
[#15557] Re: [1.9] Proc#curry — David Flanagan <david@...> 2008/02/15

ts wrote:

[#15558] Re: [1.9] Proc#curry — Yukihiro Matsumoto <matz@...> 2008/02/15

Hi,

[#15560] Re: Proc#curry — Trans <transfire@...> 2008/02/15

[#15585] Ruby M17N meeting summary — Martin Duerst <duerst@...>

This is a rough translation of the Japanese meeting summary

19 messages 2008/02/18

[#15596] possible bug in regexp lexing — Ryan Davis <ryand-ruby@...>

current:

17 messages 2008/02/19

[#15678] Re: [ANN] MacRuby — "Rick DeNatale" <rick.denatale@...>

On 2/27/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:

18 messages 2008/02/28
[#15679] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#15680] Re: [ANN] MacRuby — Yukihiro Matsumoto <matz@...> 2008/02/28

Hi,

[#15683] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[PATCH] Append srcprefix to $INCFLAGS in create_makefile

From: Daniel Berger <Daniel.Berger@...>
Date: 2008-02-01 22:24:07 UTC
List: ruby-core #15341
Hi all,

The following patch automatically appends the srcprefix to the $INCFLAGS 
in the create_makefile method.

My reasoning is that I often put private .h files in the same directory 
as the main files. These typically contain helper functions that I don't 
want to include in the main source. I don't think I'm alone in this, so 
I'd be curious to have some feedback.

If it turns out that I'm the only one who does this then I'll just 
manually append it myself in the extconf.rb file.

Regards,

Dan

--- mkmf.orig   Fri Feb  1 14:52:45 2008
+++ mkmf.rb     Fri Feb  1 14:59:46 2008
@@ -1231,7 +1231,8 @@
  # directory as your build script. This will not only eliminate the 
need for
  # you to manually copy the source files into the same directory as 
your build
  # script, but it also sets the proper +target_prefix+ in the generated
-# Makefile.
+# Makefile. In addition, the +srcprefix+ will be appended to the list of
+# $INCFLAGS if set.
  #
  # Setting the +target_prefix+ will, in turn, install the generated 
binary in
  # a directory under your Config::CONFIG['sitearchdir'] that mimics 
your local
@@ -1277,6 +1278,8 @@
      target_prefix = ""
    end

+  $INCFLAGS += " -I#{srcprefix}" if srcprefix
+
    srcprefix ||= '$(srcdir)'
    Config::expand(srcdir = srcprefix.dup)

In This Thread

Prev Next