Brandon J. Van Every wrote:
Sure. But OpenWengo isn't a patch. I'm sure everyone will be very
happy if you submit *small* patches, bug reports, and feature requests
in the bug tracker for *CMake*. Nobody wants the entireity of CMake to
be rewritten in a higher level style. They want
Yep but this is the problem...
it cannot be made of small patches, how can you integrate a kind of
inheritance system with small patches to CMake? It changes the API...
I'm not sure to understand what you call inheritance system.
There is already an inheritance system in CMake.
For instance,
Tanguy Krotoff wrote:
Brandon J. Van Every wrote:
Sure. But OpenWengo isn't a patch. I'm sure everyone will be very
happy if you submit *small* patches, bug reports, and feature
requests in the bug tracker for *CMake*. Nobody wants the entireity
of CMake to be rewritten in a higher level
Brandon J. Van Every wrote:
If you macrotize all the CMake code out of existence, then people
have to dig through your code and documentation to understand what's
going on. If people need help with what's going on, they have to ask
you, because nobody else in the CMake community knows what's
Brandon J. Van Every wrote:
Alan W. Irwin wrote:
This example of how CMake has quite casually taken over one autotoolized
project reflects in my opinion the fact that we live in a chaotic world
where small positive actions often have large positive consequences.
So in
such a world careful
On 2006-11-18 10:16-0800 Brandon J. Van Every wrote:
I would like to know in the case of PLplot, how mature the Unix / Cygwin /
MinGW / MSVC builds already were. Did they all essentially work already?
Under autotools, Linux and Mac OS X were fine, other Unices were untested.
Cygwin and
Hi Brandon,
Von: Brandon J. Van Every [EMAIL PROTECTED]
...
Then, I read the article (http://lwn.net/Articles/188693/) by Alex on
KDE's
switch from autotools to cmake. That article really resonated with me
(especially the remarks about simple CMake syntax which every developer
would
Alan W. Irwin wrote:
Our windows platform is
still not completely full-featured, but it has many more features
(plotting
devices, language front-ends, etc.) than it did before on windows
which is
why we are making a development release a week from today.
It sounds like Chicken and PLplot
Alexander Neundorf wrote:
Hi Brandon,
Von: Brandon J. Van Every [EMAIL PROTECTED]
Getting started with CMake is easy. It lulls people into a false sense
of security about the amount of work involved... which from a CMake
promotion standpoint, is a good thing. I'm cynical about what it
Brandon J. Van Every wrote:
People who feel neutral about Autoconf, or who are in fact pleased with
it, aren't going to up and do anything for Windows anytime soon. For
those people, it will take a *long* time for migrations to happen via
CMake.
I do not agree, yes it will take time but if
Length warning! As a preamble, I want to make it clear that I'm not a
proponent of Stop Energy.
http://www.userland.com/whatIsStopEnergy
I throw cold water at people, then tell them to knock themselves out
with whatever they feel needs doing.
Tanguy Krotoff wrote:
Brandon J. Van Every
On 2006-11-17 16:56-0800 Brandon J. Van Every wrote:
When projects are that expensive to re-architect, people don't just
switch. They carefully consider their options only when they're in a lot
of pain. So if a Linux-loving Autoconfer's build is working more or less
ok, they ain't fixin' what
Alan W. Irwin wrote:
[The Autotools] help was much appreciated, but
still the necessity for that help and the other factors I have mentioned
made me uneasy about continuing to depend on autotools.
Yes, the Autotools have many liabilities. Most notably, they are built
in layers, all with
Bill Hoffman wrote:
The problem with the shell, is that you can run cmake, then run make
from a different shell
For the most part that works on unix. zsh, bash, sh, csh basically
work the same. The trouble shows up
on windows.
Yep, open source on Windows is nothing but TROUBLE. It
On 2006-11-16 13:00-0800 Brandon J. Van Every wrote:
Bill Hoffman wrote:
The problem with the shell, is that you can run cmake, then run make from
a different shell
For the most part that works on unix. zsh, bash, sh, csh basically work
the same. The trouble shows up
on windows.
Alexander Neundorf wrote:
so did OpenWengo now officially switch to CMake ?
Yes we are switching, still some minor work to do
I end up creating a framework (set of macros) above CMake that
simplifies the writing of CMakeLists.txt (we have more than 100
CMakeLists.txt) + adds some features
Alexander Neundorf wrote:
CMake has some of that.
It has for OS:
UNIX
APPLE
WIN32
CYGWIN
MINGW
Cygwin is not an OS, it's a compiler.
The Bash that comes with Cygwin provides a filesystem environment.
Oftentimes when people compile on Windows in open source land, what they
really want /
Brandon J. Van Every wrote:
Alexander Neundorf wrote:
CMake has some of that.
It has for OS:
UNIX
APPLE
WIN32
CYGWIN
MINGW
Cygwin is not an OS, it's a compiler.
The Bash that comes with Cygwin provides a filesystem environment.
Oftentimes when people compile on Windows in open source
Hi Tanguy,
Von: Tanguy Krotoff [EMAIL PROTECTED]
so did OpenWengo now officially switch to CMake ?
Hi
Cmake supports several boolean for platform/compiler detection:
UNIX
APPLE
WIN32
CYGWIN
MINGW
BORLAND
I think this approach is too simple and not very easy for the developer.
Hi
Cmake supports several boolean for platform/compiler detection:
UNIX
APPLE
WIN32
CYGWIN
MINGW
BORLAND
I think this approach is too simple and not very easy for the developer.
What about code that I want to compile under Windows using Borland,
Intel, MinGW and MSVC?
What about code
20 matches
Mail list logo
