On Sunday 18 July 2010 12:07:43 you wrote:
> On Sunday 18 July 2010 09:15:17 Michael Hertling wrote:
> > On 07/18/2010 06:50 AM, Branan Riley wrote:
> > > I've mad a very cursory effort to add Python 3 support to CMake. All
> > > I've done so far is take FindPythonLibs and FindPythonInterp, and
> >
On 22. Jul, 2010, at 22:03 , Hickel, Kelly wrote:
> Thanks Michael,
> I'll give that a try tomorrow, at least setting it from the top level file,
> but this seems like exactly the thing that you'd want to do in a toolchain
> file, doesn't it? E.g. one of the build tools has a particular restri
On 07/22/2010 08:33 AM, Michael Wild wrote:
>
> On 22. Jul, 2010, at 3:09 , Michael Hertling wrote:
>
>> On 07/21/2010 10:26 AM, Michael Wild wrote:
>>>
>>> On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
>>>
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
> On 2010-07-20 17:12+0
On 07/22/2010 10:36 AM, Michael Wild wrote:
>
> On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:
> [...]
>>
>> Hi Michael and others,
>>
>> I mostly agree with what your saying. However, IMHO, you refer to a
>> "perfect world" situation, where all Find modules properly use VERSION
>> to specify a
On 07/22/2010 10:17 AM, Marcel Loose wrote:
> On Thu, 2010-07-22 at 03:09 +0200, Michael Hertling wrote:
>> On 07/21/2010 10:26 AM, Michael Wild wrote:
>>>
>>> On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
>>>
On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
> On 2010-07-20 17:12+
On Fri, Jul 23, 2010 at 12:23 AM, Michael Jackson
wrote:
>> Tweaked in what way?
>
> Usually they have special CMake variables for the specific project that the
> original sources were being built as part of. These all have to be cleaned
> up. Then sometimes you would like to add some of your own
On Jul 22, 2010, at 6:17 PM, Olaf van der Spek wrote:
On Fri, Jul 23, 2010 at 12:00 AM, Michael Jackson
wrote:
Yes, it was done already (For some of them) which is what I started
with.
But what you find is that the CMake files that someone wrote are
kinda
"tweaked" for their project and do
On Fri, Jul 23, 2010 at 12:00 AM, Michael Jackson
wrote:
> Yes, it was done already (For some of them) which is what I started with.
> But what you find is that the CMake files that someone wrote are kinda
> "tweaked" for their project and don't really work for yours so you end up
Tweaked in what
> I'm on the other side of that one. I don't know how many _days_ I have
> wasted because I linked my debug version with a release version of something
> else and had the strangest errors and app crashes. After pulling my hair out
> trying to debug something that does not need to be debugged I fina
On Jul 22, 2010, at 5:53 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 11:50 PM, Michael Jackson
wrote:
Of course I have separate projects. I didn't write libz... Did you?
DLLs should be *shared*. There shouldn't be a need for me to copy
them
to my app dir.
Well,
Actually I _di
On Jul 22, 2010, at 5:40 PM, J Decker wrote:
On Thu, Jul 22, 2010 at 2:37 PM, John Drescher
wrote:
On Thu, Jul 22, 2010 at 5:25 PM, J Decker wrote:
I'll add my two cents - I like that the names are the same, it
allows
me to switch the release out with the debug and not have to
recompil
On Thu, Jul 22, 2010 at 11:50 PM, Michael Jackson
wrote:
>> Of course I have separate projects. I didn't write libz... Did you?
>> DLLs should be *shared*. There shouldn't be a need for me to copy them
>> to my app dir.
>
> Well,
> Actually I _did_ put a CMake wrapper on LibZ that _does_ in fact
On Jul 22, 2010, at 5:42 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 11:36 PM, Michael Jackson
wrote:
How does the loader find the DLL?
Because when Visual Studio launches an executable it will look in
the same
directory that the executable resides in for libraries to load.
Now
On Thu, Jul 22, 2010 at 2:37 PM, John Drescher wrote:
> On Thu, Jul 22, 2010 at 5:25 PM, J Decker wrote:
>> I'll add my two cents - I like that the names are the same, it allows
>> me to switch the release out with the debug and not have to recompile
>> the executable.
>
>
> You are not supposed
On Thu, Jul 22, 2010 at 11:36 PM, Michael Jackson
wrote:
>> How does the loader find the DLL?
>
> Because when Visual Studio launches an executable it will look in the same
> directory that the executable resides in for libraries to load. Now, if you
> have 2 completely separate projects where one
On Jul 22, 2010, at 5:25 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 11:14 PM, Michael Jackson
wrote:
So here is what really happens with Visual Studio. When you
invoke CMake
you select to build "Shared" libraries and a Win64 application.
These are
the basics. Visual Studio wi
> You _can_ very easily do this if you want. The code is out there in the
> wild in the form of macros that can be invoked from CMake that will set all
> of this up for you. You just have to look for it (or ask the right person...
> )
>
I do this for my shared libraries although I do not put the
I'll add my two cents - I like that the names are the same, it allows
me to switch the release out with the debug and not have to recompile
the executable. Besides, I doubt your interface changes because of
debug or release mode - so the .lib should be exactly the same.
Though I suppose if you pas
On Thu, Jul 22, 2010 at 11:14 PM, Michael Jackson
wrote:
> So here is what really happens with Visual Studio. When you invoke CMake
> you select to build "Shared" libraries and a Win64 application. These are
> the basics. Visual Studio will create a subdirectory for "Debug" and
> "Release" vari
2010/7/22 Olaf van der Spek :
> On Thu, Jul 22, 2010 at 11:08 PM, Eric Noulard wrote:
>> Yes it should, if ever the proposed patch
>> http://public.kitware.com/Bug/view.php?id=10292
>> is merged as-is.
>
> What's the delay?
I do not have an authoritative answer,
I'm not Kitware employee just a ba
On Jul 22, 2010, at 4:54 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 10:46 PM, Michael Jackson
wrote:
Ya know , I go back and forth on this. In my own projects I will
give my
libs a _debug suffix because I end up installing both debug and
release into
a local directory and my Find
On Thu, Jul 22, 2010 at 11:08 PM, Eric Noulard wrote:
> Yes it should, if ever the proposed patch
> http://public.kitware.com/Bug/view.php?id=10292
> is merged as-is.
What's the delay?
Olaf
___
Powered by www.kitware.com
Visit other Kitware open-sourc
2010/7/22 Olaf van der Spek :
> On Thu, Jul 22, 2010 at 4:08 PM, Freddie Witherden
> wrote:
>> I'll try adding a check for `rpmbuild` to my CMakeLists before enabling RPM
>> packages. This seems quite a nice solution as users should always get TGZ
>> and DEB and RPM if possible. From what I ga
On Thu, Jul 22, 2010 at 10:46 PM, Michael Jackson
wrote:
> Ya know , I go back and forth on this. In my own projects I will give my
> libs a _debug suffix because I end up installing both debug and release into
> a local directory and my FindXXX.cmake scripts know to look for both a debug
> and re
On Thu, Jul 22, 2010 at 10:46 PM, John Drescher wrote:
> On Thu, Jul 22, 2010 at 4:43 PM, Olaf van der Spek
> wrote:
>> On Thu, Jul 22, 2010 at 10:41 PM, John Drescher wrote:
And then what? Having two DLLs with the same name is not going to
work. Same for import or static libs.
>>>
>>
On Jul 22, 2010, at 4:38 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 10:32 PM, Ryan Pavlik
wrote:
Unfortunately there are as many ways to denote these differences as
there
are projects. However, unless you're setting the
ARCHIVE_OUTPUT_DIRECTORY,
LIBRARY_OUTPUT_DIRECTORY, or RUNTI
On Thu, Jul 22, 2010 at 4:43 PM, Olaf van der Spek wrote:
> On Thu, Jul 22, 2010 at 10:41 PM, John Drescher wrote:
>>> And then what? Having two DLLs with the same name is not going to
>>> work. Same for import or static libs.
>>
>> It would work fine if the dlls for multiple configurations were
On Thu, Jul 22, 2010 at 10:41 PM, John Drescher wrote:
>> And then what? Having two DLLs with the same name is not going to
>> work. Same for import or static libs.
>
> It would work fine if the dlls for multiple configurations were not
> all dumped in 1 folder. That is how I have used cmake for 2
> And then what? Having two DLLs with the same name is not going to
> work. Same for import or static libs.
It would work fine if the dlls for multiple configurations were not
all dumped in 1 folder. That is how I have used cmake for 2+ years.
John
___
On Thu, Jul 22, 2010 at 10:32 PM, Ryan Pavlik wrote:
> Unfortunately there are as many ways to denote these differences as there
> are projects. However, unless you're setting the ARCHIVE_OUTPUT_DIRECTORY,
> LIBRARY_OUTPUT_DIRECTORY, or RUNTIME_OUTPUT_DIRECTORY (and if you are, I
> highly suggest
On Thu, Jul 22, 2010 at 10:32 PM, John Drescher wrote:
>> Shouldn't this be done automatically?
>
> No way. Not all users would want that on all platforms that CMake
> supports.
Who is talking about all platforms?
> Also it is very easy to add a single line to your
> CMakeLists.txt file..
So?
> Shouldn't this be done automatically?
No way. Not all users would want that on all platforms that CMake
supports. Also it is very easy to add a single line to your
CMakeLists.txt file..
> What about shared vs static lib?
> Shared vs static runtime?
> x64 vs x86?
You can do all of that similarl
On 7/22/2010 3:23 PM, Olaf van der Spek wrote:
On Thu, Jul 22, 2010 at 9:23 PM, Ryan Pavlik wrote:
On 7/22/10 10:08 AM, Olaf van der Spek wrote:
Hi,
All target names have the same base name. So both the debug and
release variant are called xbt.lib. However, I've only got a single
lib dir.
On Thu, Jul 22, 2010 at 9:23 PM, Ryan Pavlik wrote:
> On 7/22/10 10:08 AM, Olaf van der Spek wrote:
>>
>> Hi,
>>
>> All target names have the same base name. So both the debug and
>> release variant are called xbt.lib. However, I've only got a single
>> lib dir. Shouldn't all variants have a uniq
Thanks Michael,
I'll give that a try tomorrow, at least setting it from the top level file,
but this seems like exactly the thing that you'd want to do in a toolchain
file, doesn't it? E.g. one of the build tools has a particular restriction,
and you need to change the template when using that
I just wanted to post this solution. But why don't you set this in the
top-level CMakeLists.txt file? Also, you can use a loop over the languages and
string(REGEX REPLACE ...) to make things a bit safer:
foreach(lang C CXX)
foreach(type CREATE APPEND)
string(REGEX REPLACE "()(.*)()" "\\3 \
On 7/22/10 10:08 AM, Olaf van der Spek wrote:
Hi,
All target names have the same base name. So both the debug and
release variant are called xbt.lib. However, I've only got a single
lib dir. Shouldn't all variants have a unique name?
Olaf
set(CMAKE_DEBUG_POSTFIX _d)
See the documentation for
It turns out that you can do this (yay!), it's just tricky to discover how
(well, it was for ME!).
I got to wondering when CMake was injecting the STATIC_LIBRARY_FLAGS into the
ar command line. The answer to this is also the reason why my setting
LINK_FLAGS didn't have any effect on the ar comm
On Thu, Jul 22, 2010 at 7:43 PM, Tyler Roscoe wrote:
> On Thu, Jul 22, 2010 at 04:57:50PM +0200, Olaf van der Spek wrote:
>> Why aren't empty dirs excluded by default?
>
> Because if they were excluded, we would have someone on the list next
> month asking why she can't create empty directories wi
On Thu, Jul 22, 2010 at 04:57:50PM +0200, Olaf van der Spek wrote:
> Why aren't empty dirs excluded by default?
Because if they were excluded, we would have someone on the list next
month asking why she can't create empty directories with install()
commands.
tyler
Hello,
It seems the debug/release default configuration are only built for VStudio
suites.
Anyway I am trying to simulated such for the codeblocks IDE, this is how I
did my CMakeLists.txt :
project( myapp )
add_executable( Release WIN32 ${my_src_files} )
target_link_libraries( Release ${my_libs
> -Original Message-
> From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
> Behalf Of Verweij, Arjen
> Sent: Thursday, July 22, 2010 6:59 AM
> To: cmake@cmake.org
> Subject: Re: [CMake] how to set ar/ranlib flags per target
>
> Hi Kelly,
>
> I'm using cmake to migrate from
>>>True, but note the "*.h" filter. After the filter, the dir is empty,
so it doesn't make any sense to create it at install time.
Yep I tried it and as you say .svn appears even though the "filter" should
grab .h files
So I echo Olafs's question why is .svn dir grabed when .h filter should be
en
On 22. Jul, 2010, at 17:07 , kent williams wrote:
> It's perfectly clear to me now, but I bet I'm not the first (or last!)
> person to run into issues like this and get roadblocked.
>
> Every software task seems to have its stumbling block.
>
> In Medical Image Processing we spend a lot of our
Thank you Michael,
I was afraid about this but I had to ask to try anyways :s
On Thu, Jul 22, 2010 at 4:09 PM, Michael Wild wrote:
>
> On 22. Jul, 2010, at 15:57 , David Ojeda wrote:
>
> > Hello CMakers!
> >
> > I am coding with some teammates that use Xcode as their IDE. Everything
> is
> > wo
On Thu, Jul 22, 2010 at 5:05 PM, Brian Davis wrote:
>>> It does, but should not be necessary. Why aren't empty dirs excluded by
>>> default?
>
> svn directory is not empty.. it is hidden, but not empty... at least it
True, but note the "*.h" filter. After the filter, the dir is empty,
so it doesn
Hi,
All target names have the same base name. So both the debug and
release variant are called xbt.lib. However, I've only got a single
lib dir. Shouldn't all variants have a unique name?
Olaf
___
Powered by www.kitware.com
Visit other Kitware open-sou
It's perfectly clear to me now, but I bet I'm not the first (or last!)
person to run into issues like this and get roadblocked.
Every software task seems to have its stumbling block.
In Medical Image Processing we spend a lot of our time debugging
issues related to how image volumes are oriented/
>> It does, but should not be necessary. Why aren't empty dirs excluded by
default?
svn directory is not empty.. it is hidden, but not empty... at least it
shouldn't be if the svn is working correctly. I am probably missing
something here and should give this a try myself as I currently am using
On Thu, Jul 22, 2010 at 4:56 PM, Brian Davis wrote:
> You could switch to git :-) so there are not all these .svn dirs splatted
> all over the tree... One of the many things I hate about svn and love about
> git. But in all seriousness try using the PATTERN "svn" EXCLUDE. I have
> not used this,
You could switch to git :-) so there are not all these .svn dirs splatted
all over the tree... One of the many things I hate about svn and love about
git. But in all seriousness try using the PATTERN "svn" EXCLUDE. I have
not used this, let me know if it works.
install(DIRECTORY icons scripts/
>
> Good idea but this seems difficult to do.
> In Olaf case it may be doable to spit out a better error message
> explicitely
> saying that "T" was considered as the "" argument of PROJECT,
> because PROJECT is a builtin
>
> I was just agreeing with Olaf and stating a issue I ran into on error
rep
Hi,
install(DIRECTORY xbt DESTINATION include FILES_MATCHING PATTERN "*.h")
install(TARGETS xbt DESTINATION lib)
How do I exclude empty dirs, like .svn from being created?
Why is it necessary to specify DESTINATION lib? Can't it use a default?
Olaf
__
On 07/22/2010 09:43 AM, Mathieu Malaterre wrote:
> Hi there,
>
> I am trying to build ITK from a toplevel directory, my application
> is setup simply like this:
>
> $ cat CMakeLists.txt
> project(MySuperApp)
> find_package(VTK REQUIRED)
> message("${VTK_VERSION}")
> add_subdirectory(ITK) # cont
On Thu, Jul 22, 2010 at 4:08 PM, Freddie Witherden
wrote:
> I'll try adding a check for `rpmbuild` to my CMakeLists before enabling RPM
> packages. This seems quite a nice solution as users should always get TGZ
> and DEB and RPM if possible. From what I gather producing DEBs has no
> associa
On 22. Jul, 2010, at 15:57 , David Ojeda wrote:
> Hello CMakers!
>
> I am coding with some teammates that use Xcode as their IDE. Everything is
> working fine thanks to CMake, except for the following situation:
>
> 1. Developer X checkouts a project from svn and uses CMake to generate their
>
On 22 Jul 2010, at 07:02, Rolf Eike Beer wrote:
> Am Thursday 22 July 2010 schrieb Freddie Witherden:
>> I wish to know how I can have CMake/CPack determine if it is possible to
>> build an RPM or DEB package on the system (so if all the required
>> utilities are installed) and if so to go ahead an
Hello CMakers!
I am coding with some teammates that use Xcode as their IDE. Everything is
working fine thanks to CMake, except for the following situation:
1. Developer X checkouts a project from svn and uses CMake to generate their
Xcode project
2. Developer X succesfully compiles their executab
Hi there,
I am trying to build ITK from a toplevel directory, my application
is setup simply like this:
$ cat CMakeLists.txt
project(MySuperApp)
find_package(VTK REQUIRED)
message("${VTK_VERSION}")
add_subdirectory(ITK) # contains the ITK source
Since cmake 2.8 find_package now sets VTK_VERSIO
Brad,
I found another repository with jom binaries. It works fine with 0.9.4.
Apparently the original link I used to download JOM was ancient.
Thanks,
Arjen
>-Original Message-
>From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
>Of Verweij, Arjen
>Sent: woensdag 2
Dear all,
I'm stucked with the evaluation of an environment variable when running
parallel tests from ctest_test command. This environment variable is
the 'TMPDIR' containing the machine file needed for mpiexec.
After removing the uneeded lines, my submission sequence looks like the
following:
Hi all,
That sounds like a good solution. It is probably the cleanest way to
solve this controversy. OTOH, it adds two extra keywords that, of
course, are not used in existing (now sometimes failing) Find macros.
IMHO, solving the issue by changing CMake's behaviour would be
preferable, using a po
Hi Kelly,
I'm using cmake to migrate from a legacy build system. The source consists of C
C++ Fortran and Fortran90. I think -in all- there are 15 binaries.
One of the problems for us is linking. Cmake somehow decides to take compiler X
to link executable Y. But in some cases it didn't use the
Arjen, I saw your response about "wrapping add_library" on the list, but for
some reason it didn't get to my inbox.
I'm not sure what you mean by "wrapping", are you talking about a code change,
or some sort of macro? So far, I haven't been able to come up with any way of
jamming -X64 into the
Thanks for reminding me of my old idea ;-)
http://www.cmake.org/pipermail/cmake/2010-May/036993.html
I think that would be the cleanest solution. Extract the loop body into a
function and then have two separate loops calling the same function.
Michael
On 22. Jul, 2010, at 13:19 , David Cole wr
With respect to fixing 10718, *if* we fix it (and that's a big *if* because
it's a sweeping change in behavior with largely unpredictable real world
consequences), I suggest that we:
- have both loops in CMake,
- and that the default behavior remains the same as it is now,
- and that we activate th
2010/7/22 Olaf van der Spek :
> On Thu, Jul 22, 2010 at 11:33 AM, Eric Noulard wrote:
>> Note that you can search the bug tracker using filter for CPack or DEB etc...
>
> I can set Category = CPack, but where can I set DEB?
There is no "DEB" (nor TGZ, NSIS etc...) Category but you do a keyword s
I'd just like to confirm that I've seen exactly the same bug since
upgrading from 2.8.0 to 2.8.1.
I've submitted a bug at:
http://public.kitware.com/Bug/view.php?id=11026
On 21/07/10 16:06, Bill Hoffman wrote:
On 7/21/2010 10:41 AM, Emmanuel Christophe wrote:
Hi Dave,
Thanks for the informati
On Thu, Jul 22, 2010 at 11:33 AM, Eric Noulard wrote:
> Note that you can search the bug tracker using filter for CPack or DEB etc...
I can set Category = CPack, but where can I set DEB?
Olaf
___
Powered by www.kitware.com
Visit other Kitware open-sou
2010/7/22 Olaf van der Spek :
> On Thu, Jul 22, 2010 at 10:56 AM, Eric Noulard wrote:
>> 2010/7/22 Olaf van der Spek :
>>> On Wed, Jul 21, 2010 at 7:40 PM, Eric Noulard
>>> wrote:
http://public.kitware.com/Bug/view.php?id=9900
>>>
>>> What's stopping this bug from being fixed?
>>
>> From my
On Thu, Jul 22, 2010 at 10:56 AM, Eric Noulard wrote:
> 2010/7/22 Olaf van der Spek :
>> On Wed, Jul 21, 2010 at 7:40 PM, Eric Noulard wrote:
>>> http://public.kitware.com/Bug/view.php?id=9900
>>
>> What's stopping this bug from being fixed?
>
> From my point of view: lack of time :-)
> However f
2010/7/22 Olaf van der Spek :
> On Wed, Jul 21, 2010 at 7:40 PM, Eric Noulard wrote:
>> http://public.kitware.com/Bug/view.php?id=9900
>
> What's stopping this bug from being fixed?
>From my point of view: lack of time :-)
However for my next CMake developping session
[which is not planned] this
On Wed, Jul 21, 2010 at 7:40 PM, Eric Noulard wrote:
> http://public.kitware.com/Bug/view.php?id=9900
What's stopping this bug from being fixed?
Olaf
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/op
On 22. Jul, 2010, at 10:17 , Marcel Loose wrote:
[...]
>
> Hi Michael and others,
>
> I mostly agree with what your saying. However, IMHO, you refer to a
> "perfect world" situation, where all Find modules properly use VERSION
> to specify a version number and do not abuse NAMES for that.
>
> I
2010/7/21 Brian Davis :
> I agree with Olaf. CMake needs better error reporting for parameter
> checking on macros and functions
Good idea but this seems difficult to do.
In Olaf case it may be doable to spit out a better error message explicitely
saying that "T" was considered as the "" argument
On Thu, 2010-07-22 at 03:09 +0200, Michael Hertling wrote:
> On 07/21/2010 10:26 AM, Michael Wild wrote:
> >
> > On 21. Jul, 2010, at 9:56 , Marcel Loose wrote:
> >
> >> On Tue, 2010-07-20 at 09:18 -0700, Alan W. Irwin wrote:
> >>> On 2010-07-20 17:12+0200 Michael Hertling wrote:
> >>>
> On
On 22. Jul, 2010, at 9:55 , norulez wrote:
> I want to set the debug prefix on windows when I build in debug mode, so I
> check if Debug is in CMAKE_BUILD_TYPE.
> I use both, Visual Studio and the MinGW compiler
>
> Am 22.07.2010 um 08:53 schrieb Michael Wild :
>
>>
>> On 22. Jul, 2010, at 8:
I want to set the debug prefix on windows when I build in debug mode, so I
check if Debug is in CMAKE_BUILD_TYPE.
I use both, Visual Studio and the MinGW compiler
Am 22.07.2010 um 08:53 schrieb Michael Wild :
>
> On 22. Jul, 2010, at 8:38 , norulez wrote:
>
>> How can I find out which build ty
On 22. Jul, 2010, at 9:18 , Alan W. Irwin wrote:
> On 2010-07-22 03:09+0200 Michael Hertling wrote:
>> [...] one should
>> prefer to improve the find modules and get rid of those non-equivalent
>> alternatives after the NAMES option, in particular hardcoded version
>> lists, and freshly develope
Forgot the list
-- Forwarded message --
From: Eric Noulard
Date: 2010/7/22
Subject: Re: [CMake] CPack: Detecting if to build DEB/RPM packages
To: norulez
2010/7/22 norulez :
> This shouldn't work, because you could build deb packages on redhat systems
> with cpack without any
2010/7/22 Freddie Witherden :
> Hi,
>
> I use CPack in my project to build binary packages as an alternative to `make
> install`. However, I am interested in getting my project to automatically
> detect which packages to build.
>
> Currently I have TGZ set and then require the user to pass the app
On 2010-07-22 03:09+0200 Michael Hertling wrote:
In summary, my point is: Even if the loops are swapped, we wouldn't get
a solution that works well in real-world scenarios so I doubt if it's
worth the effort [...].
Hi Michael:
I think find issues are a really important topic so I am glad you
82 matches
Mail list logo
