Re: [Mingw-users] configure error

[Keith Marshall <keithmarshall@us...>]

On Thursday 09 October 2008 17:14:23 Robert wrote:
> ah, hehe, thanks, knew it was something blatantly obvious, im only
> a first year comp sci student, i know i have a lot to learn...

Not least of it being that you shouldn't top post on mailing lists.

> JonY wrote:
> > On 10/9/2008 23:16, Robert wrote:
> >> Hi, I am following the wiki (http://www.mingw.org/wiki/msys) to
> >> install msys+mingw,
> >>
> >> at the following step i get an error...
> >>
> >> "Using MSYS with MinGW
> >> The autotools that are installed by MSYS DTK do not work well
> >> and can't build DLLs. If you need newer versions of autoconf,
> >> automake and libtool then follow these instructions.
> >> We will install autoconf, automake and libtool.
> >>
> >>     * You will need to download updated versions.
> >>           o autoconf<http://ftp.gnu.org/gnu/autoconf/>;
> >> ...
> >> 
> >> ./configure --prefix=/mingw&&  make&&  make install"
> >>
> >> [...]
> >
> > did you "cd" into the unpacked directories? Sorry if it wasn't
> > obvious in the guide.

With recent autoconf, make sure you read the comments attached to that 
wiki article -- in particular the one about *not* configuring and 
building in the source directory.  If you have updated your MSYS make 
to version 3.81, it exposes a bug in autoconf, (which I know afflicts 
autoconf-2.61 through 2.63), and which makes it impossible to build 
using the above commands.

You should build in a separate directory, outside of the source 
hierarchy; that's actually good practice to adopt for *any* package, 
unless it absolutely does not support such a building method, (known 
as a VPATH build, and supported by any autoconfiscated package).

FTR, here's the sequence of commands I recommend, for building 
autoconf-2.63:--

  $ tar xzf autoconf-2.63.tar.gz
  $ mkdir -p build/autoconf-2.63
  $ cd build/autoconf-2.63
  $ ../../autoconf-2.63/configure --prefix=/mingw
  $ make
  $ make check
  $ make install

Do note that the `make check' step is optional; it confirms that the 
build has been completed successfully, but it  is rather slow -- it 
takes about 7 hours on my MSYS box.  If you don't care for the peace 
of mind it affords, you may omit it.

HTH,
Keith.

Re: [Mingw-users] make is super slow

[Earnie Boyd <earnie@us...>]

Quoting Bob Rossi <bob@...>:

Just to answer this:
>
> The second question I have is, how could I get a relative path to a
> shared drive? If I map it to z:/, how do get a relative path to it?
>

mkdir /project
cd /project
junction mysrc z:/path/to/src
mkdir mybld
cd mybld
../mysrc/configure ...

Earnie

Re: [Mingw-users] make is super slow

[Earnie Boyd <earnie@us...>]

Quoting Bob Rossi <bob@...>:

>
> Seems like just cutting down on all those implicit rules helps a lot.
>
> Does autoconf generate any rules that depends on implicit rules of
> make? If not, perhaps it should use the -r option by default somehow?
>

Implicit rules give an automatic definition of what a source file 
ending in .c (as an example) is supposed to do to produce the target 
file ending in .o.  If your makefile defines those rules then removing 
the implicit rules you don't need will have a definite performance 
impact.  If you're working in the MSYS or Cygwin shell you can always 
do ``alias make='make -r''' in your ~/.profile file to create your 
default value.

Earnie

Re: [Mingw-users] make is super slow

[Earnie Boyd <earnie@us...>]

Quoting Bob Rossi <bob@...>:

>
> Yes, VPATH ends up having this,
>  VPATH=z:/path/to/dir
> srcdir, top_srcdir, abs_srcdir and abs_top_srcdir also have this
> style path in that configuration.
>

VPATH now has a list of paths; z and /path/to/dir; these end up being 
relative to the current working directory drive.  The other variables 
are probably alright but may be problematic especially if that are used 
in targets.

Earnie

Re: [Mingw-users] /dev/urandom

[John Brown <johnbrown105@ho...>]

Tor Lilqvist wrote:

> Soren Andersen wrote:
>
>> Oh, and I concur. I would never trust encryption software from
>> someone as completely clueless as you are.
>
> Except that it wasn't Paul who asked the initial question, it was
> Arjan van Vliet...
>
> --tml
>

HAHAHAHAHAHAHAHAHAHA

_________________________________________________________________
Stay up to date on your PC, the Web, and your mobile phone with Windows Live.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/

Re: [Mingw-users] make is super slow

[Earnie Boyd <earnie@us...>]

Quoting Bob Rossi <bob@...>:

>
> In both of those configurations, make itself is terribly slow. I now
> find that if I run 'make -r' this dramatically improves the speed.
> It goes from about 8 minutes to 30 seconds. That's a 16x speed
> improvement. So, it's at a speed that is OK for me now.
>

Removing the builtin-rules may be a good choice if you know that you 
have the rules created manually to take care of the targets.  It would 
help to remove many stats to the filesystem.

Earnie

Re: [Mingw-users] make is super slow

[Ralf Wildenhues <Ralf.Wildenhues@gm...>]

Hi Bob,

* Bob Rossi wrote on Thu, Oct 09, 2008 at 04:20:30PM CEST:
> 
> You came in a little late, and I botched up the thread, because my mail
> wasn't working. So, here is a little refresher.

Thanks; and apologies for not reading the whole thread beforehand.

> I now wanted to try building from a common source tree. So, have the
> source on a network drive, but the build dir on a local drive. I was
> successfully able to get autotools to work to my suprise by doing,
> 
> //path/to/configure 
> /z/path/to/configure 

(BTW, why were you surprised about that?)

> In both of those configurations, make itself is terribly slow. I now
> find that if I run 'make -r' this dramatically improves the speed.

Because it omits lots of stat calls (or whatever the w32 equivalent)
for possible prerequisite files, due to all those pattern rules that
GNU make has built-in.

> The question is, does automake generated Makefile's depend on the -r
> feature? If not, why not always have this off, I'd imagine this would
> improve performance for a lot of tols.

I *think* automake doesn't depend on it.  I'll make a note to try to
test this somehow in a unit test; and anyway I'd consider it a bug if
automake's rules did depend on it.

But many users' Makefile.am files implicitly rely on GNU make-provided
pattern rules.  They probably shouldn't, but let's face it, many
developers never use anything other than GNU make, be that by choice or
by lack of better knowledge.  So, in general it cannot be turned off.

FWIW, we may want to move this part of the discussion to the automake
list, because it turns a bit off-topic here.  (If there is more to
discuss, that is.)

> The second question I have is, how could I get a relative path to a 
> shared drive? If I map it to z:/, how do get a relative path to it?

Even if, I don't think it would help; I'd guess it's the file lookups
that take so long.

Cheers,
Ralf

[Mingw-users] Odd link messages. Are they dangerous?

[Bruce M. Axtens <bruce.axtens@gm...>]

I used the MinGW .a to Windows .lib transformation process as detailed 
in a thread on the gmp-discuss list, as below (acting against a GMP 
4.2.4 library created with --disable-shared --enable-static.)

cp libgmp.a gmp.a
ranlib gmp.a
mv gmp.a gmp.lib

I now have a .lib file against which VC++6 seems to have no difficulty 
linking. What concerns me now is warning messages I'm getting from the 
link phase:

LINK : warning LNK4049: locally defined symbol "___mb_cur_max" imported
LINK : warning LNK4049: locally defined symbol "__pctype" imported
LINK : warning LNK4049: locally defined symbol "__iob" imported

At this point in the proceedings these make no difference to the running 
of my DLL (which wraps certain GMP functionality). But is that good 
enough? Will having these three symbols from libgmp.a linked in to my 
Windows DLL end up biting me later on?

Kind regards,
Bruce.

Re: [Mingw-users] /dev/urandom

[Tor Lillqvist <tml@ik...>]

> Oh, and I concur. I would never trust encryption software from
> someone as completely clueless as you are.

Except that it wasn't Paul who asked the initial question, it was
Arjan van Vliet...

--tml

Re: [Mingw-users] /dev/urandom

[Soren Andersen <somian@bl...>]

Replying to post on Thu, 09 Oct 2008 11:14:15 -0400 from "Paul Peaslee":

> Paul 'Bo' Peaslee
> Database Administrator
> Maine Medical Center
> peaslpw@...
> 207.662.6523

^^ This garbage ^^ is unwanted on technical mailing lists.

> >>> On 10/8/2008 at 10:54 PM, Earnie Boyd
> >>> <email obscured> wrote:

^^ Do not quote ^^ people's email addresses, please.

> "Please check out the http://www.mingw.org/mailing_lists and the
> section titled "Etiquette"."
>  
> Hmmmm, then it is OK to flame someone, rudely.  Just don't top post.

You haven't been flamed rudely. Yet.

Please read http://www.catb.org/~esr/faqs/smart-questions.html#intro

> Paul

> CONFIDENTIALITY NOTICE:  This email message, including any
> attachments, is for the use of the intended recipient(s) only and may
> contain information that is privileged, confidential, and prohibited
> from unauthorized disclosure under applicable law.  If you are not
> the intended recipient of this message, any dissemination,
> distribution, or copying of this message is strictly prohibited.  If
> you received this message in error, please notify the sender by reply
> email and destroy all copies of the original message and attachments.

^^ This garbage ^^ is exceedingly obnoxious and is unwelcome on
technical mailing lists

Here's the part where you get flamed, Mr. Peaslee.

You are an arrogant twit. You display the kind of arrogance that
masquerades as what people call "thin skin" and is really an
extreme, nearly pathological inability to suspend the personal
ego in a situation in which you are in the position of ignorance
about customs and protocols as well as about technical
knowledge. This ego, a miserable petty tyrant if ever one
existed, doesn't care whether it stops you from learning or
causes you to be blocked out by people who could have helped you
in the future. All it cares about is that you don't "tolerate
anyone being rude" to you (i.e., challenging or tweaking this
tyrannical ego).

Quoting the above cited document:
   [...]
   If you find this attitude obnoxious, condescending, or arrogant,
   check your assumptions. We're not asking you to genuflect to us
   — in fact, most of us would love nothing more than to deal with
   you as an equal and welcome you into our culture, if you put in
   the effort required to make that possible. But it's simply not
   efficient for us to try to help people who are not willing to
   help themselves. It's OK to be ignorant; it's not OK to play
   stupid.

   If you decide to come to us for help, you don't want to
   be one of the losers. You don't want to seem like one,
   either. The best way to get a rapid and responsive answer is
   to ask it like a person with smarts, confidence, and clues
   who just happens to need help on one particular problem.

Your choice. I will now have all email from you screened out
so you won't be seeing any further responses from me,
personally.  Life is really too short (I'm in my 40s) to
have to deal with people suffering your degree of inflamed
egomania. I don't care about your job, your boss, your
pressures, your mortgage, your sick dog, your miserable
marriage, any of it. I don't share your quasi-religion of fake
niceness that masks vicious cruelty and intolerance behind a
glaze of distraction. You can take it all and just shove it up
your you-know-what. It isn't my problem.

Oh, and I concur. I would never trust encryption software from
someone as completely clueless as you are. Encryption software
is something that matters.

   Soren Andersen

Re: [Mingw-users] configure error

[Robert <rob.waffles@gm...>]

ah, hehe, thanks, knew it was something blatantly obvious, im only a 
first year comp sci student, i know i have a lot to learn...

JonY wrote:
> On 10/9/2008 23:16, Robert wrote:
>   
>> Hi, I am following the wiki (http://www.mingw.org/wiki/msys) to install
>> msys+mingw,
>>
>> at the following step i get an error...
>>
>> "Using MSYS with MinGW
>> The autotools that are installed by MSYS DTK do not work well and can't
>> build DLLs. If you need newer versions of autoconf, automake and libtool
>> then follow these instructions.
>> We will install autoconf, automake and libtool.
>>
>>     * You will need to download updated versions.
>>           o autoconf<http://ftp.gnu.org/gnu/autoconf/>;
>>           o automake<http://ftp.gnu.org/gnu/automake/>;
>>           o libtool<http://ftp.gnu.org/gnu/libtool/>;
>>
>>     * Unpack autoconf, automake and libtool to a directory of your choice.
>>     * Install them with the 3 with the following command:
>>
>> ./configure --prefix=/mingw&&  make&&  make install"
>>
>>
>> the error is
>> "
>> $ ./configure --prefix=/mingw&&  make&&  make install
>> sh: ./configure: No such file or directory
>> "
>>
>> Wondering what i have missed...
>>
>> Thanks for your time,
>>                       Robert
>>
>>     
>
> Hi,
> did you "cd" into the unpacked directories? Sorry if it wasn't obvious 
> in the guide.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>
>   

Re: [Mingw-users] configure error

[JonY <10walls@gm...>]

On 10/9/2008 23:16, Robert wrote:
> Hi, I am following the wiki (http://www.mingw.org/wiki/msys) to install
> msys+mingw,
>
> at the following step i get an error...
>
> "Using MSYS with MinGW
> The autotools that are installed by MSYS DTK do not work well and can't
> build DLLs. If you need newer versions of autoconf, automake and libtool
> then follow these instructions.
> We will install autoconf, automake and libtool.
>
>     * You will need to download updated versions.
>           o autoconf<http://ftp.gnu.org/gnu/autoconf/>;
>           o automake<http://ftp.gnu.org/gnu/automake/>;
>           o libtool<http://ftp.gnu.org/gnu/libtool/>;
>
>     * Unpack autoconf, automake and libtool to a directory of your choice.
>     * Install them with the 3 with the following command:
>
> ./configure --prefix=/mingw&&  make&&  make install"
>
>
> the error is
> "
> $ ./configure --prefix=/mingw&&  make&&  make install
> sh: ./configure: No such file or directory
> "
>
> Wondering what i have missed...
>
> Thanks for your time,
>                       Robert
>

Hi,
did you "cd" into the unpacked directories? Sorry if it wasn't obvious 
in the guide.

Re: [Mingw-users] configure error

[Soren Andersen <somian@bl...>]

In response to Thu, 09 Oct 2008 23:16:07 +0800's send by Robert:

> Hi, I am following the wiki (http://www.mingw.org/wiki/msys) to
> install msys+mingw,
> 
> at the following step i get an error...
> 
> "Using MSYS with MinGW
> The autotools that are installed by MSYS DTK do not work well and
> can't build DLLs. If you need newer versions of autoconf, automake
> and libtool then follow these instructions.
> We will install autoconf, automake and libtool.
> 
>    * You will need to download updated versions.
>          o autoconf <http://ftp.gnu.org/gnu/autoconf/>;
>          o automake <http://ftp.gnu.org/gnu/automake/>;
>          o libtool <http://ftp.gnu.org/gnu/libtool/>;
> 
>    * Unpack autoconf, automake and libtool to a directory of your
> choice.
>    * Install them with the 3 with the following command:
> 
> ../configure --prefix=/mingw && make && make install"
> 
> the error is
> "
> $ ./configure --prefix=/mingw && make && make install
> sh: ./configure: No such file or directory
> "
> 
> Wondering what i have missed...

http://www.gnu.org/software/autoconf/manual/html_node/Running-configure-Scripts.html#Running-configure-Scripts

or in case of email evil: http://tinyurl.com/3jyue2

If this is truly the first time that you've encountered a
`configure' script, you have a lot of knowledge to assimilate.

   Regards,
      Soren Andersen

Re: [Mingw-users] perl 5.8?

[Soren Andersen <somian@bl...>]

Quoting Earnie Boyd as he wrote on Thu, 09 Oct
2008 06:32:00 -0400

> Quoting Sisyphus <sisyphus1@...>:
> 
> >
> > You can, of course, run any Windows perl (including ActiveState and
> > Strawberry builds) from within the MSYS shell.
> >
> 
> But be aware that the perl scripts would need to contain windows
> paths and not unix paths.

Yes, since a native Windows Perl won't be linked to MSYS' DLL
and so couldn't understand absolute pathnames like /c/bing.bmp
(or however MSYS does it ...it's been a while).

However, it's actually not very common in my experience to have
a true need to hard-code an absolute path in a Perl program.
Doing so may in fact be a sign of bad programming practice more
than anything else, except when it isn't (there are always
exceptions). More commonly a relative pathname will do just
fine.

When people read "Windows path" I am not sure what they are going
to think that means. Unfortunately for those of us who like
things to be done right, many times people have had a grossly
unclear notion of what it means, in fact. They think all sorts
of stuff that isn't true based on myths that the ignorant have
unfortunately repeated to others over and over again.

How many times have we seen something like this in a Perl
program?:
 if ($^O =~ /MSWin/i) { # have to use backslashes on Windows,grr
   $pathname = ".\\MyMess\\goes\\Here";
 } else {
   $pathname = "./MyMess/goes/Here";
 }

 open my($FH), $pathname or
  die "Why doesn't anything ever go easily!?!";

Heh ;-/.  That's a relative path and the condition is completely
unnecessary. All Perls use the canonical forward slash
internally and when the Windows OS gets the request to open()
the pathname with canonical slashes it does not blink an "eye".

Basically, the only Unix-ism that you have to avoid in scripts
run by a native MS Windows Perl under MSYS is "/X/" (the root
directory followed by the Windows drive [volume] letter). That
shouldn't be too hard to do for many programmers.

   Thanks for letting me wax pedantic,
            Soren Andersen

[Mingw-users] configure error

[Robert <rob.waffles@gm...>]

Hi, I am following the wiki (http://www.mingw.org/wiki/msys) to install 
msys+mingw,

at the following step i get an error...

"Using MSYS with MinGW
The autotools that are installed by MSYS DTK do not work well and can't 
build DLLs. If you need newer versions of autoconf, automake and libtool 
then follow these instructions.
We will install autoconf, automake and libtool.

   * You will need to download updated versions.
         o autoconf <http://ftp.gnu.org/gnu/autoconf/>;
         o automake <http://ftp.gnu.org/gnu/automake/>;
         o libtool <http://ftp.gnu.org/gnu/libtool/>;

   * Unpack autoconf, automake and libtool to a directory of your choice.
   * Install them with the 3 with the following command:

./configure --prefix=/mingw && make && make install"


the error is
"
$ ./configure --prefix=/mingw && make && make install
sh: ./configure: No such file or directory
"

Wondering what i have missed...

Thanks for your time,
                     Robert

Re: [Mingw-users] /dev/urandom

[Paul Peaslee <PEASLPW@mm...>]

Paul 'Bo' Peaslee
Database Administrator
Maine Medical Center
peaslpw@...
207.662.6523
 
 
>>> On 10/8/2008 at 10:54 PM, Earnie Boyd <earnie@...> wrote:
"Please check out the http://www.mingw.org/mailing_lists and the section 
titled "Etiquette"."
 
Hmmmm, then it is OK to flame someone, rudely.  Just don't top post.
 
Paul



CONFIDENTIALITY NOTICE:  This email message, including any attachments, is for the use of the intended recipient(s) only and may contain information that is privileged, confidential, and prohibited from unauthorized disclosure under applicable law.  If you are not the intended recipient of this message, any dissemination, distribution, or copying of this message is strictly prohibited.  If you received this message in error, please notify the sender by reply email and destroy all copies of the original message and attachments.

Re: [Mingw-users] perl 5.8?

[Paul Peaslee <PEASLPW@mm...>]

Paul 'Bo' Peaslee
Database Administrator
Maine Medical Center
peaslpw@...
207.662.6523
 
 
>>> On 10/9/2008 at 6:32 AM, Earnie Boyd <earnie@...> wrote:
"But be aware that the perl scripts would need to contain windows paths 
and not unix paths."

 
Does that imply that if you use the perl packaged with MSYS that you don't have to use Windows paths?

CONFIDENTIALITY NOTICE:  This email message, including any attachments, is for the use of the intended recipient(s) only and may contain information that is privileged, confidential, and prohibited from unauthorized disclosure under applicable law.  If you are not the intended recipient of this message, any dissemination, distribution, or copying of this message is strictly prohibited.  If you received this message in error, please notify the sender by reply email and destroy all copies of the original message and attachments.

Re: [Mingw-users] make is super slow

[Bob Rossi <bob@br...>]

On Thu, Oct 09, 2008 at 01:22:26PM +0200, Ralf Wildenhues wrote:
> * Bob Rossi wrote on Thu, Oct 09, 2008 at 01:04:34PM CEST:
> > On Thu, Oct 09, 2008 at 06:47:44AM -0400, Earnie Boyd wrote:
> > 
> > > Where in the Makefile is the z:/path/to/configure set?  VPATH and 
> > > targets would be problematic for a Windows style path.
> > 
> > Yes, VPATH ends up having this,
> >   VPATH=z:/path/to/dir
> > srcdir, top_srcdir, abs_srcdir and abs_top_srcdir also have this 
> > style path in that configuration.
> > 
> > Here is some interesting information.
> 
> > Seems like just cutting down on all those implicit rules helps a lot.
> > 
> > Does autoconf generate any rules that depends on implicit rules of 
> > make? If not, perhaps it should use the -r option by default somehow?
> 
> Can't you just use relative paths?  ./configure or ../source/configure
> leads to $(srcdir) being relative.  Don't use /absolute/path/configure 
> (although it should work, it is generally not preferable).

Hi Ralf,

You came in a little late, and I botched up the thread, because my mail
wasn't working. So, here is a little refresher.

I can build locally by checking out the source locally, and building
locally. When I do that, I build with relative paths and everything
works great. (../configure ...)

I now wanted to try building from a common source tree. So, have the
source on a network drive, but the build dir on a local drive. I was
successfully able to get autotools to work to my suprise by doing,

//path/to/configure 
/z/path/to/configure 

Where Z: is a network map of //path/to in this case.

In both of those configurations, make itself is terribly slow. I now
find that if I run 'make -r' this dramatically improves the speed.
It goes from about 8 minutes to 30 seconds. That's a 16x speed
improvement. So, it's at a speed that is OK for me now.

The question is, does automake generated Makefile's depend on the -r
feature? If not, why not always have this off, I'd imagine this would
improve performance for a lot of tols.

The second question I have is, how could I get a relative path to a 
shared drive? If I map it to z:/, how do get a relative path to it?

Thanks,
Bob Rossi

Re: [Mingw-users] make is super slow

[Ralf Wildenhues <Ralf.Wildenhues@gm...>]

* Bob Rossi wrote on Thu, Oct 09, 2008 at 01:04:34PM CEST:
> On Thu, Oct 09, 2008 at 06:47:44AM -0400, Earnie Boyd wrote:
> 
> > Where in the Makefile is the z:/path/to/configure set?  VPATH and 
> > targets would be problematic for a Windows style path.
> 
> Yes, VPATH ends up having this,
>   VPATH=z:/path/to/dir
> srcdir, top_srcdir, abs_srcdir and abs_top_srcdir also have this 
> style path in that configuration.
> 
> Here is some interesting information.

> Seems like just cutting down on all those implicit rules helps a lot.
> 
> Does autoconf generate any rules that depends on implicit rules of 
> make? If not, perhaps it should use the -r option by default somehow?

Can't you just use relative paths?  ./configure or ../source/configure
leads to $(srcdir) being relative.  Don't use /absolute/path/configure 
(although it should work, it is generally not preferable).

Cheers,
Ralf

Re: [Mingw-users] Is russian allowed here?

[Bread.Short <bread.short@go...>]

On Thu, 09 Oct 2008 06:43:54 -0400
Earnie Boyd <earnie@...> wrote:

> This is an English only list.  If you find a support list that speaks 
> Russian let us know.  We could add a wiki page for other language 
> support.

Okay. 

-- 
Bread.Short <bread.short@...>

Re: [Mingw-users] make is super slow

[Bob Rossi <bob@br...>]

On Thu, Oct 09, 2008 at 06:47:44AM -0400, Earnie Boyd wrote:
> 
> Quoting Rüdiger Ranft <_rdi_@...>:
> 
> > Bob Rossi schrieb:
> >
> >> Then make still takes a really long time at each target.
> >> Even targets like, 'make  all-am' hang for tens of seconds.
> >>
> >> If I configure like this,
> >>   z:/path/to/configure .....
> >> configure finishes fine, but my make fails. It actually goes fast
> >> at the points where it is otherwise slow, but then it says "no rule
> >> to make target....".
> >>
> >> Any more ideas?
> >
> > Maybe make -d give some insights. Also make -n is woth a try, because it
> > will not start any programs but only shows what it want to do.

Thanks, that helped me thing of trying the -r option, because make went 
on forever with trying implicit rules.

> Where in the Makefile is the z:/path/to/configure set?  VPATH and 
> targets would be problematic for a Windows style path.

Yes, VPATH ends up having this,
  VPATH=z:/path/to/dir
srcdir, top_srcdir, abs_srcdir and abs_top_srcdir also have this 
style path in that configuration.

Here is some interesting information.

make check
real    8m45.672s
user    0m24.379s
sys     1m42.076s

make -r check
real    0m27.437s
user    0m6.828s
sys     0m4.158s

Seems like just cutting down on all those implicit rules helps a lot.

Does autoconf generate any rules that depends on implicit rules of 
make? If not, perhaps it should use the -r option by default somehow?

Thanks,
Bob Rossi

Re: [Mingw-users] make is super slow

[Earnie Boyd <earnie@us...>]

Quoting Rüdiger Ranft <_rdi_@...>:

> Bob Rossi schrieb:
>
>> Then make still takes a really long time at each target.
>> Even targets like, 'make  all-am' hang for tens of seconds.
>>
>> If I configure like this,
>>   z:/path/to/configure .....
>> configure finishes fine, but my make fails. It actually goes fast
>> at the points where it is otherwise slow, but then it says "no rule
>> to make target....".
>>
>> Any more ideas?
>
> Maybe make -d give some insights. Also make -n is woth a try, because it
> will not start any programs but only shows what it want to do.
>

Where in the Makefile is the z:/path/to/configure set?  VPATH and 
targets would be problematic for a Windows style path.

Earnie

Re: [Mingw-users] Is russian allowed here?

[Earnie Boyd <earnie@us...>]

Quoting "Bread.Short" <bread.short@...>:

This is an English only list.  If you find a support list that speaks 
Russian let us know.  We could add a wiki page for other language 
support.

Earnie

Re: [Mingw-users] perl 5.8?

[Earnie Boyd <earnie@us...>]

Quoting Sisyphus <sisyphus1@...>:

>
> You can, of course, run any Windows perl (including ActiveState and
> Strawberry builds) from within the MSYS shell.
>

But be aware that the perl scripts would need to contain windows paths 
and not unix paths.

Earnie

Re: [Mingw-users] perl 5.8?

[Sisyphus <sisyphus1@op...>]

----- Original Message ----- 
From: "Caleb Cushing" <xenoterracide@...>
To: <mingw-users@...>
Sent: Thursday, October 09, 2008 7:04 PM
Subject: [Mingw-users] perl 5.8?


> seems when I installed msys and mingw a while back I found a tarball
> with 5.8 in it. is this still around? I don't seem to be able to find
> it now.

You're possibly thinking of the "MSYS Supplementary Tools" which you'll find 
at:
http://sourceforge.net/project/showfiles.php?group_id=2435

But that contains perl-5.6.1. (I'm not aware of a perl-5.8 having been made 
available.)

You can, of course, run any Windows perl (including ActiveState and 
Strawberry builds) from within the MSYS shell.

Cheers,
Rob