--- Howard Chu <[EMAIL PROTECTED]> wrote:
> Keith MARSHALL wrote:
> > BRM wrote:
> >> I´ve been playing around with it a bit today,
> mostly
> >> MSYS, and have thus far only had one issue with
> it -
> >> cl won´t compile the program because of bad
> parameters
> >> being passed to it (since MSYS
Keith MARSHALL wrote:
BRM wrote:
I´ve been playing around with it a bit today, mostly
MSYS, and have thus far only had one issue with it -
cl won´t compile the program because of bad parameters
being passed to it (since MSYS uses // instead of /).
(Not sure if that´s an issue for you guys, mingw
BRM wrote:
> I´ve been playing around with it a bit today, mostly
> MSYS, and have thus far only had one issue with it -
> cl won´t compile the program because of bad parameters
> being passed to it (since MSYS uses // instead of /).
> (Not sure if that´s an issue for you guys, mingw-msys,
> or the
Howard Chu wrote, quoting BRM:
>> I´m taking a look at Msys/MingW now. Its worked best
>> so far - though a script is failing. I got it to run
>> by running the VC build environment (e.g. vcvars.bat)
>> and then running the msys environment (msys.bat) to
>> enter into the msys shell.
>>
>> Thanks f
Brian Dessent wrote:
So really in a way using Cygwin with -mno-cygwin and using MSYS are the
same conceptual thing.
Yes, the code produced by Cygwin's gcc -mno-cygwin should be identical
to that produced by the MinGW gcc. We recommend MSYS anyway because
building with MSYS is significantly f
BRM wrote:
I tried building a little environment to allow the
scripts to run. I got it to detect them, and execute
them, but then ran into the problem that Perl has
cmd.exe hard-coded instead of referencing %COMSPEC%
(like it should) so any script it tries to execute
after the primary one won´t
Thanks all for the help. It´s been very insightful.
I´ve been playing around with it a bit today, mostly
MSYS, and have thus far only had one issue with it -
cl won´t compile the program because of bad parameters
being passed to it (since MSYS uses // instead of /).
(Not sure if that´s an issue fo
BRM wrote:
> I wouldn´t mind using Cygwin as the build environment.
> What I mind is having to have any dependancy from the
> Cygwin build environment come into my project. As much
> as I may like to, I can´t open source the project (not
> my call to do so), and my customers won´t install
> anythi
--- David Boreham <[EMAIL PROTECTED]> wrote:
> >Does anyone know of a project that could help solve
> >the problem? I guess, I am primarily looking for a
> >non-intrusive cmd.exe replacement for Windows 2000
> >Pro.
> Are you trying to avoid installing Cygwin for your
> build
> environment, or avoi
Does anyone know of a project that could help solve
the problem? I guess, I am primarily looking for a
non-intrusive cmd.exe replacement for Windows 2000
Pro.
Are you trying to avoid installing Cygwin for your build
environment, or avoid Cygwin in your runtime environment ?
If the latter, th
It sounds like you want to use MinGW (http://www.mingw.org/) rather
than Cygwin. When used in conjunction with the MSYS shell
environment, MinGW allows building normal WIN32 applications with no
dependence on anything but standard WIN32 DLLs.
Bob
On Fri, 9 Dec 2005, BRM wrote:
I want to be
I want to be able to run the AutoTool chain natively
under Windows. I did some looking around, and
everyone´s answer primarily seems to be ¨run Cygwin¨.
Unfortunately, Cygwin is not an option for me as I
can´t tell my clients to install Cygwin to use my
product. (They´d go to someone else.) Same ap
12 matches
Mail list logo
