On Saturday 07 March 2009 20:45:55 Philip Lowman wrote:
> I have no plans to develop a package manager from the work done in
> CMakePorts. As I've stated in other mailing lists like sldev, I think that
> would be a waste of time.
My apologies, rereading the messages that led me to draw that conclu
On Sat, Mar 7, 2009 at 6:21 AM, Mike Arthur wrote:
> On Saturday 07 March 2009 11:08:43 Pau Garcia i Quiles wrote:
> > Whatever happened to this?
> It's here:
> http://code.google.com/p/cmakeports/
>
> People are talking on the group list here and some stuff has been
> committed.
>
> Unfortunatel
On Sat, Mar 7, 2009 at 6:42 AM, Peter Drahos wrote:
> Hi,
> I'm one of the developers of LuaDist (Lua module distribution and build
> system) that uses CMake for building. Its rather simple "ports"-like tool
> that can install Lua modules and few libraries that we CM'd, including
> simple version
On Saturday 07 March 2009 11:08:43 Pau Garcia i Quiles wrote:
> Whatever happened to this?
It's here:
http://code.google.com/p/cmakeports/
People are talking on the group list here and some stuff has been committed.
Unfortunately I personally have the feeling that it's starting as a bit
overengi
Whatever happened to this?
On Mon, Feb 16, 2009 at 2:50 AM, Philip Lowman wrote:
> Hi,
>
> Luigi suggested a kind of CMake ports system in a recent thread here on the
> CMake mailing list. This would presumably be a system whereby popular 3rd
> party dependencies which have not yet CMakeified th
On Friday 20 February 2009, Philip Lowman wrote:
> On Thu, Feb 19, 2009 at 3:38 PM, Alexander Neundorf
>
> > wrote:
> >
> > On Wednesday 18 February 2009, Philip Lowman wrote:
> > > This is an interesting idea.
> > >
> > > One thought I had was the potential of new features creeping into the
> >
On Thu, Feb 19, 2009 at 3:38 PM, Alexander Neundorf wrote:
> On Wednesday 18 February 2009, Philip Lowman wrote:
> > This is an interesting idea.
> >
> > One thought I had was the potential of new features creeping into the
> CMake
> > module you're downloading that aren't yet available in the C
On Wednesday 18 February 2009, Philip Lowman wrote:
> On Tue, Feb 17, 2009 at 4:19 PM, Eric Noulard wrote:
...
> > if FORCE_UPDATE is YES/TRUE then the module would be updated everytime
> > cmake is run.
> > The default would be not to update if the file is already there locally.
> >
> > So then CM
On Tue, Feb 17, 2009 at 4:26 PM, Eric Noulard wrote:
> 2009/2/16 Bill Hoffman :
> > Philip Lowman wrote:
> >>
> >> A tertiary goal would be convincing the 3rd party dependencies to switch
> >> to CMake for their native build systems.
>
> I don't really like the "propaganda" idea :-)
>
> Particular
On Tue, Feb 17, 2009 at 4:19 PM, Eric Noulard wrote:
> 2009/2/17 Eric Noulard :
> > 2009/2/17 Alexander Neundorf :
> >>>
> >>> But a http://autoconf-archive.cryp.to/ type archive for CMake modules
> >>> would also be a good idea.
> >>
> >> At FOSDEM we also discussed about something like this, som
On Tue, Feb 17, 2009 at 12:09 PM, Bill Hoffman wrote:
> Also, it would be really great if we setup a dashboard for this project. I
> am thinking it could all be checked out and built on a variety of
> compilers/OS's nightly.
Wouldn't have it any other way. :)
--
Philip Lowman
Eric Noulard wrote:
2009/2/16 Bill Hoffman :
Philip Lowman wrote:
A tertiary goal would be convincing the 3rd party dependencies to switch
to CMake for their native build systems.
I don't really like the "propaganda" idea :-)
Particularly for Open Source projects.
Open Source is about choic
2009/2/16 Bill Hoffman :
> Philip Lowman wrote:
>>
>> A tertiary goal would be convincing the 3rd party dependencies to switch
>> to CMake for their native build systems.
I don't really like the "propaganda" idea :-)
Particularly for Open Source projects.
Open Source is about choice and openess.
2009/2/17 Eric Noulard :
> 2009/2/17 Alexander Neundorf :
>>>
>>> But a http://autoconf-archive.cryp.to/ type archive for CMake modules
>>> would also be a good idea.
>>
>> At FOSDEM we also discussed about something like this, some kind of
>> semi-official place where to get additional cmake files
2009/2/17 Alexander Neundorf :
>>
>> But a http://autoconf-archive.cryp.to/ type archive for CMake modules
>> would also be a good idea.
>
> At FOSDEM we also discussed about something like this, some kind of
> semi-official place where to get additional cmake files.
> Right now you can look in sev
On Tuesday 17 February 2009, Bill Hoffman wrote:
> Aaron Turner wrote:
...
> > Honestly, I think in the long run, improving the existing standard
> > library of Cmake modules to allow developers to concentrate on how to
> > build their own code rather then figure out how to link to various
> > libr
BRM wrote:
I read through this thread, and I think there may be a better route -
Instead of trying to create all kinds of patches, etc; why not make a
simple tool to convert an autotool project to CMake and vice-versa?
Perhaps call it 'autotool2cmake'?
This way, the process becomes simpler:
Aaron Turner wrote:
Trying to get up to speed on this thread- apologies if I missed this.
Long story short, as an OSS developer and new Cmake user, I'm less
interested in getting libfoo building with Cmake and a lot more
interested in CMake modules for detecting and using libfoo in my own
projec
iling List ; a.neundorf-w...@gmx.net
Sent: Tuesday, February 17, 2009 8:29:07 AM
Subject: Re: [CMake] open source project for CMake ports?
On Mon, Feb 16, 2009 at 6:41 PM, Luigi Calori wrote:
Alexander Neundorf ha scritto:
I do not see value in keeping sources (as VTK does) apart from avoid the
dow
Trying to get up to speed on this thread- apologies if I missed this.
Long story short, as an OSS developer and new Cmake user, I'm less
interested in getting libfoo building with Cmake and a lot more
interested in CMake modules for detecting and using libfoo in my own
project. In reality, these
AddExternalProject is related. It can be used to download files as custom
build steps. (And then configure, build, install... other projects.)
It is only in CVS CMake right now, but it is on its way to maturing to the
point where it could be used for a project like this fairly quickly.
On Tue, F
Bill Hoffman ha scritto:
Philip Lowman wrote:
For the first cut I think starting out with keeping the CMakified
sources in the project would be fine. Many people are never going to
want anything more complicated than this and we know that this will
at least work for now.
CMake can alread
On Tuesday 17 February 2009, you wrote:
...
> Of course, you can debate forever whether such a SF project would be
> successful or not, but the only way to really know is to try it and see.
> That is, start with something small and expand from there. I don't have
> time to help with such a SF proje
Patrick Spendrin wrote:
Does this sound interesting?
Yes.
As I am maintaining patches for some libraries and working for some
others, it would be nice to have such a unified system to keep doubled
work amount low.
This has some more points:
We would not have to maintain our patches in our ow
Philip Lowman wrote:
For the first cut I think starting out with keeping the CMakified
sources in the project would be fine. Many people are never going to
want anything more complicated than this and we know that this will at
least work for now.
CMake can already untar with -E mode. Add
On Tue, Feb 17, 2009 at 6:54 AM, Mike Arthur wrote:
> On Tuesday 17 February 2009 02:24:17 Alan W. Irwin wrote:
> > Of course, you can debate forever whether such a SF project would be
> > successful or not, but the only way to really know is to try it and see.
> > That is, start with something s
On Mon, Feb 16, 2009 at 6:41 PM, Luigi Calori wrote:
> Alexander Neundorf ha scritto:
>
> I do not see value in keeping sources (as VTK does) apart from avoid the
> download-expand step.
> If the cmake scripts use glob rex expr to get source files, it should be
> quite resilient to project change
On Mon, Feb 16, 2009 at 4:36 PM, Alexander Neundorf wrote:
> > Since many of the dependencies overlap, is there general interest in
> this
> > kind of a thing from the VTK perspective or from others?
> >
> > The goal would be to create an open-source project (hosted probably at a
> > neutral sit
On Tuesday 17 February 2009 02:24:17 Alan W. Irwin wrote:
> Of course, you can debate forever whether such a SF project would be
> successful or not, but the only way to really know is to try it and see.
> That is, start with something small and expand from there. I don't have
> time to help with s
Philip Lowman schrieb:
Hi,
Luigi suggested a kind of CMake ports system in a recent thread here on
the CMake mailing list. This would presumably be a system whereby
popular 3rd party dependencies which have not yet CMakeified their
source trees could be CM'd and baselined in one place and ul
On 2009-02-17 00:41+0100 Luigi Calori wrote:
I think also the KDE-on-Windows developer cmakeified a few projects.
I' ve checked out the [KDE-on-Windows] project, it is really inetresting, I' ve tried their
emerge utility (a kind of a port of the Gentoo portage tools on windows)
It seems it is
On Sun, Feb 15, 2009 at 11:30 PM, Bill Hoffman wrote:
> Philip Lowman wrote:
>
>> Hi,
>>
>> Luigi suggested a kind of CMake ports system in a recent thread here on
>> the CMake mailing list. This would presumably be a system whereby popular
>> 3rd party dependencies which have not yet CMakeified
Alexander Neundorf ha scritto:
On Monday 16 February 2009, Philip Lowman wrote:
Hi,
Luigi suggested a kind of CMake ports system in a recent thread here on the
CMake mailing list. This would presumably be a system whereby popular 3rd
party dependencies which have not yet CMakeified their so
On Monday 16 February 2009, Philip Lowman wrote:
> Hi,
>
> Luigi suggested a kind of CMake ports system in a recent thread here on the
> CMake mailing list. This would presumably be a system whereby popular 3rd
> party dependencies which have not yet CMakeified their source trees could
> be CM'd a
Philip Lowman wrote:
Hi,
Luigi suggested a kind of CMake ports system in a recent thread here on
the CMake mailing list. This would presumably be a system whereby
popular 3rd party dependencies which have not yet CMakeified their
source trees could be CM'd and baselined in one place and ulti
Hi,
Luigi suggested a kind of CMake ports system in a recent thread here on the
CMake mailing list. This would presumably be a system whereby popular 3rd
party dependencies which have not yet CMakeified their source trees could be
CM'd and baselined in one place and ultimately downloaded for easy
36 matches
Mail list logo