Brandon Van Every wrote:
On 10/23/07, Bill Hoffman <[EMAIL PROTECTED]> wrote:
OK, now this is more what I was asking for. If autotools based
projects in msys install into /usr/local by default, then maybe CMake
ones should as well.
As far as I'm concerned, this is Autotools' problem. CMake
On 10/23/07, Bill Hoffman <[EMAIL PROTECTED]> wrote:
>
> OK, now this is more what I was asking for. If autotools based
> projects in msys install into /usr/local by default, then maybe CMake
> ones should as well.
As far as I'm concerned, this is Autotools' problem. CMake should
pursue no slav
On 10/23/07, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
> > Native windows applications do not belong in
> > /usr/local (since they don't even know what /usr/local is).
>
> But mingw or cygwin under windows will ALWAYS link against the microsoft
> runtime, regardless of whether you compile cmake
Gonzalo Garramuño wrote:
Bill Hoffman wrote:
Perhaps it would help if you explained your use case.
Sure, I'll give you several examples.
Why would you want to build MSVC and an MSYS version of your software
on the same machine?
To follow your advice from some months ago, where you spec
Bill Hoffman wrote:
The C++ code did not "forget" anything. I intentionally do not set
the CMAKE_INSTALL_PREFIX to the equivalent of /usr/local in a windows
PATH because I think it is the wrong default. I still think that it
is correct to install into program files. The only case where I w
On 10/21/07, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> The only case where I would
> accept /usr/local as the default for make install for msys, is if
> someone made a native msys version of cmake that linked to the msys run
> time. That would be a cmake used for creating other msys applications
>
Gonzalo Garramuño wrote:
Bill Hoffman wrote:
Looks like a nice patch that you can put in your cmakelist files. I
still do not think it should go in CMake. I don't think that things
built by cmake that are native windows things belong in the /usr/local
mount point of msys. If you do, it i
On 10/21/07, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
>
> Also it uselessly...
>
> ... (which is somewhat disturbing).
It seems you have strong opinions on what should be correct behavior
and what is good coding style. How you choose to present those
opinions probably matters as to how others
Bill Hoffman wrote:
Looks like a nice patch that you can put in your cmakelist files. I
still do not think it should go in CMake. I don't think that things
built by cmake that are native windows things belong in the /usr/local
mount point of msys. If you do, it is easy enough to change yo
On 10/19/07, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
>
> a) All unix autotools utilities (or other libs like ffmpeg) built under
> mingw/msys will not install in $PROGRAMFILES, which leads to cmake's
> approach being totally backwards with the rest of msys.
Actually, last I checked 2+ years a
On 10/19/07, Gonzalo Garramuño <[EMAIL PROTECTED]> wrote:
> Brandon Van Every wrote:
> >
> > Agreed, having gone through this debate awhile ago. I would further
> > note that MinGW doesn't require MSYS, and that one would of course
> > expect %ProgramFiles% as the default in that case. Adding MSY
Gonzalo Garramuño wrote:
Bill Hoffman wrote:
But hey CMake is open source, you can always add the code you want by
yourself.
Here it is... I put some questions in the comments as I'm not that
familiar with the subtleties of some cmake's commands.
You probably want to clean it up. Took me
Bill Hoffman wrote:
But hey CMake is open source, you can always add the code you want by
yourself.
Here it is... I put some questions in the comments as I'm not that
familiar with the subtleties of some cmake's commands.
You probably want to clean it up. Took me too long to write (love
Hello,
I just want to make a point here that usually the CMake developers
(Bill included) make every effort to tailor CMake to the users needs
and that this is simply something that, although controversial, is the
way it is supposed to be. That is, I would have to agree with Bill
here.
More below
Gonzalo Garramuño wrote:
Andreas Pakulat wrote:
But exactly that is not supposed to happen.
Why not? Maybe I was not clear:
cmake2.5 has a "MSYS Makefile" generator.
I did -G "MSYS Makefile" and I got an install on $PROGRAMFILES. That's
not correct.
If I wanted to install in $PROGRAMFIL
On 20.10.07 06:17:56, Gonzalo Garramuño wrote:
> Andreas Pakulat wrote:
> >But exactly that is not supposed to happen.
>
> Why not? Maybe I was not clear:
Or maybe I didn't read that part of the thread :)
> cmake2.5 has a "MSYS Makefile" generator.
Aah, ok. I take back all I said. The MSYS Ma
Andreas Pakulat wrote:
But exactly that is not supposed to happen.
Why not? Maybe I was not clear:
cmake2.5 has a "MSYS Makefile" generator.
I did -G "MSYS Makefile" and I got an install on $PROGRAMFILES. That's
not correct.
If I wanted to install in $PROGRAMFILES, there's NMake Makefile
Bill Hoffman wrote:
>
> Not really true, cygwin has its own symlinks. See here:
> http://www.cygwin.com/cygwin-ug-net/using.html
That's not a symlink. That's a mount point.
And it does not effect anything I said. Just try putting such a mount
point on PATH (which is special). It will get tr
On 19.10.07 20:12:54, Gonzalo Garramuño wrote:
> Bill Hoffman wrote:
>
> >There is no way to tell at cmake time what the user intends to use the code
> >for. If the user of cmake is building a windows app, which is the standard
> >use case for MinGW, then it you don't want /usr/local.
>
> I d
Gonzalo Garramuño wrote:
What you want to do is extend the msys environment with extra POSIX
compatible tools.
No. I was just trying to compile cmake (or other stuff) under msys and
have it behave like all other (subset of) autotools libraries or
executables that can be compiled under s
Bill Hoffman wrote:
There is no way to tell at cmake time what the user intends to use the
code for. If the user of cmake is building a windows app, which is the
standard use case for MinGW, then it you don't want /usr/local.
I disagree. You can infer how MinGW is being used by looking at
Gonzalo Garramuño wrote:
Bill Hoffman wrote:
That is not a bug. MSYS in its "charter" explicitly says it does not
want to become a new cygwin. The tools in msys are available only for
support of the compiler tool chain. The main goal is to build native
windows applications with the mingw too
Bill Hoffman wrote:
That is not a bug. MSYS in its "charter" explicitly says it does not
want to become a new cygwin. The tools in msys are available only for
support of the compiler tool chain. The main goal is to build native
windows applications with the mingw tool chain. If you want posi
Brandon Van Every wrote:
Agreed, having gone through this debate awhile ago. I would further
note that MinGW doesn't require MSYS, and that one would of course
expect %ProgramFiles% as the default in that case. Adding MSYS
doesn't change the compiler being used, and the MSYS philosophy is as
B
On 10/19/07, Bill Hoffman <[EMAIL PROTECTED]> wrote:
> Gonzalo Garramuño wrote:
> >
> > Compiling CMake HEAD with mingw. After install, it defaulted to
> > installing in $PROGRAMFILES/CMake, instead of /usr/local/ (ie.
> > C:/msys/1.0/usr/local) incorrectly overwriting my MSVC version.
> >
> >
> >
Gonzalo Garramuño wrote:
Compiling CMake HEAD with mingw. After install, it defaulted to
installing in $PROGRAMFILES/CMake, instead of /usr/local/ (ie.
C:/msys/1.0/usr/local) incorrectly overwriting my MSVC version.
That is not a bug. MSYS in its "charter" explicitly says it does not
Compiling CMake HEAD with mingw. After install, it defaulted to
installing in $PROGRAMFILES/CMake, instead of /usr/local/ (ie.
C:/msys/1.0/usr/local) incorrectly overwriting my MSVC version.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy
27 matches
Mail list logo
