On 3/15/2013 5:14 PM, marco atzeri wrote:
On 3/15/2013 4:41 PM, Bill Hoffman wrote:
On 3/15/2013 11:31 AM, marco atzeri wrote:
ok, found.
I do not need to malloc the space for the win32_path
assigning again the pointer does not work.
Next step, to check if no other issues on 64bit
Yes, that w
On 3/15/2013 4:41 PM, Bill Hoffman wrote:
On 3/15/2013 11:31 AM, marco atzeri wrote:
ok, found.
I do not need to malloc the space for the win32_path
assigning again the pointer does not work.
Next step, to check if no other issues on 64bit
Yes, that would do it... If you allocate new memory
On 3/15/2013 11:31 AM, marco atzeri wrote:
ok, found.
I do not need to malloc the space for the win32_path
assigning again the pointer does not work.
Next step, to check if no other issues on 64bit
Yes, that would do it... If you allocate new memory then the
information never gets passed back
On 3/15/2013 4:00 PM, marco atzeri wrote:
On 3/15/2013 3:24 PM, Bill Hoffman wrote:
On 3/15/2013 7:17 AM, marco atzeri wrote:
Dear Bill,
we are starting to port packages on cygwin at 64 bit
http://cygwin.com/ml/cygwin-apps/2013-03/msg00070.html
Of course a cmake version for that platform will
On 3/15/2013 3:24 PM, Bill Hoffman wrote:
On 3/15/2013 7:17 AM, marco atzeri wrote:
Dear Bill,
we are starting to port packages on cygwin at 64 bit
http://cygwin.com/ml/cygwin-apps/2013-03/msg00070.html
Of course a cmake version for that platform will be helpful;
I tried to build the current s
On 3/15/2013 7:17 AM, marco atzeri wrote:
Dear Bill,
we are starting to port packages on cygwin at 64 bit
http://cygwin.com/ml/cygwin-apps/2013-03/msg00070.html
Of course a cmake version for that platform will be helpful;
I tried to build the current source and the first obstacle is that
the de
Dear Bill,
we are starting to port packages on cygwin at 64 bit
http://cygwin.com/ml/cygwin-apps/2013-03/msg00070.html
Of course a cmake version for that platform will be helpful;
I tried to build the current source and the first obstacle is that
the deprecated "cygwin_conv_to_win32_path" functi
On 2/7/2012 6:19 PM, Robert Dailey wrote:
+1 to this as well
My bad. I will get to it this week. They don't make it that easy...
-Bill
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topi
+1 to this as well
-
Robert Dailey
On Tue, Feb 7, 2012 at 4:16 PM, marco atzeri wrote:
> Hi Bill,
> any plan to update the cygwin package ?
>
> Currently we are still on 2.8.4-1
>
> Regards
> Marco
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http
Hi Bill,
any plan to update the cygwin package ?
Currently we are still on 2.8.4-1
Regards
Marco
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.c
On Thu, Oct 28, 2010 at 12:49:16PM -0500, Yaakov (Cygwin/X) wrote:
> We see the defining of WIN32 on Cygwin as a *bug*, not a feature, and it
> needs to be fixed outright.
I think the crux of the dilemma is this: what do you say to the people
who rely on this "buggy" behavior for their packages
On Thu, 2010-10-28 at 09:39 -0400, Marcus D. Hanwell wrote:
> It seems that the policy based approach would have allowed you a one
> line patch to most packages (changing the policy to NEW).
Look at this from the POV of a packager: even a one-line patch adds up
quickly when you talk about hundreds
--- Gio 28/10/10, Marcus D. Hanwell ha scritto:
> It seems that the policy based approach would have allowed
> you a one
> line patch to most packages (changing the policy to NEW).
I guess so. I can work with a one single line patch.
> Marcus
Marco
___
On Thu, Oct 28, 2010 at 8:45 AM, Marco Atzeri wrote:
> --- Mer 27/10/10, Marcus D. Hanwell ha scritto:
>
>> On Wed, Oct 27, 2010 at 2:38 PM, Alan
>> W. Irwin
>
>> wrote:
>> > On 2010-10-26 17:53-0400 Bill Hoffman wrote:
>> >
>> >> The policy mechanism might not be ideal but in a
>> year or so, al
--- Mer 27/10/10, Marcus D. Hanwell ha scritto:
> On Wed, Oct 27, 2010 at 2:38 PM, Alan
> W. Irwin
> wrote:
> > On 2010-10-26 17:53-0400 Bill Hoffman wrote:
> >
> >> The policy mechanism might not be ideal but in a
> year or so, all of this
> >> would go away, and the meantime the patches you
>
--- Mer 27/10/10, Alan W. Irwin ha scritto:
> On 2010-10-26 17:53-0400 Bill Hoffman
> wrote:
>
> > The policy mechanism might not be ideal but in a year
> or so, all of this would go away, and the meantime the
> patches you have to maintain for cygwin ports would become
> trivial. The patch wou
--- Mer 27/10/10, Clinton Stimpson ha scritto:
> I did see in the Cygwin overview that the Win32 api should
> generally be
> avoided.
>
> However, its probably misleading that chapter 4,
> "Programming with Cygwin,"
> shows Win32 code instead of Unix code in the examples.
> http://cygwin.com/c
--- Mer 27/10/10, Alexander Neundorf ha scritto:
> > >> I suppose one other options is something like
> this:
> > >>
> > >> "Warning: CMake has be forced to break
> backwards
> > >> compatibility by the cygwin ports
> maintainers, we apologize
> > >> if this broke your code. If your code does
> n
On Wednesday 27 October 2010, Michael Wild wrote:
> On 27. Oct, 2010, at 12:38 , Marco Atzeri wrote:
> > --- Mer 27/10/10, Bill Hoffman ha scritto:
> >> On 10/26/2010 9:58 PM, Yaakov
> >>
> >> (Cygwin/X) wrote:
> >>> On Tue, 2010-10-26 at 17:53 -0400, Bill Hoffman
> >>
> >> wrote:
> Backwards
On Wed, Oct 27, 2010 at 2:38 PM, Alan W. Irwin
wrote:
> On 2010-10-26 17:53-0400 Bill Hoffman wrote:
>
>> The policy mechanism might not be ideal but in a year or so, all of this
>> would go away, and the meantime the patches you have to maintain for cygwin
>> ports would become trivial. The patc
On 2010-10-26 17:53-0400 Bill Hoffman wrote:
The policy mechanism might not be ideal but in a year or so, all of this
would go away, and the meantime the patches you have to maintain for cygwin
ports would become trivial. The patch would basically have a set cmake
version at the top. I thou
On 27. Oct, 2010, at 12:38 , Marco Atzeri wrote:
> --- Mer 27/10/10, Bill Hoffman ha scritto:
>
>> On 10/26/2010 9:58 PM, Yaakov
>> (Cygwin/X) wrote:
>>> On Tue, 2010-10-26 at 17:53 -0400, Bill Hoffman
>> wrote:
Backwards compatibility may not be important to
>> you, but to CMake it is
>>>
--- Mer 27/10/10, Bill Hoffman ha scritto:
> On 10/26/2010 9:58 PM, Yaakov
> (Cygwin/X) wrote:
> > On Tue, 2010-10-26 at 17:53 -0400, Bill Hoffman
> wrote:
> >> Backwards compatibility may not be important to
> you, but to CMake it is
> >> very important. When a developer chooses to
> use CMake,
On 10/26/2010 9:58 PM, Yaakov (Cygwin/X) wrote:
On Tue, 2010-10-26 at 17:53 -0400, Bill Hoffman wrote:
Backwards compatibility may not be important to you, but to CMake it is
very important. When a developer chooses to use CMake, I want to
respect that choice, and work as hard as I can to make
On Tue, 2010-10-26 at 17:53 -0400, Bill Hoffman wrote:
> Backwards compatibility may not be important to you, but to CMake it is
> very important. When a developer chooses to use CMake, I want to
> respect that choice, and work as hard as I can to make sure I don't
> break that code. CMake ha
So, I think the only way to fix this is to create a new policy. The
policy will warn all cygwin builds that CMake is no longer defining
WIN32 on cygwin. As with all policies, if a project has the minimum
required CMake set to the version of CMake that implements the policy
the new behavior wi
On Tue, 2010-10-26 at 08:15 -0400, Bill Hoffman wrote:
> At the end of the day, CMake should be following the majority of the
> cygwin applications. However, I really don't want to break the code of
> the people that have spent the time to get applications working on
> cygwin with CMake over th
On 10/24/2010 11:52 PM, Yaakov (Cygwin/X) wrote:
On Fri, 2010-10-22 at 13:12 +, Rolf Eike Beer wrote:
So this is only different from what other build tools or whatever do. But
it is well known behaviour, it is documented, and it can't be changed for
backward compatibility anyway.
The only
On Mon, 2010-10-25 at 07:57 +0200, Hendrik Sattler wrote:
> No. You have the same kernel under the skin and any software that has low-
> level parts thus needs to know that it is running on Windows, be it through
> the cygwin layer or not. How does it do that without the WIN32 define?
With the CY
--- Lun 25/10/10, Hendrik Sattler ha scritto:
> Am Montag 25 Oktober 2010, 05:44:27
> schrieb Yaakov (Cygwin/X):
> > On Sun, 2010-10-24 at 10:12 +0200, Hendrik Sattler
> wrote:
> > > And: believe it or not, WIN32 and CYGWIN are
> _not_ in strong contrast.
> > > They've got so much in common, star
Am Montag 25 Oktober 2010, 05:44:27 schrieb Yaakov (Cygwin/X):
> On Sun, 2010-10-24 at 10:12 +0200, Hendrik Sattler wrote:
> > And: believe it or not, WIN32 and CYGWIN are _not_ in strong contrast.
> > They've got so much in common, starting from the binary file format to
> > all low level stuff th
On Fri, 2010-10-22 at 13:12 +, Rolf Eike Beer wrote:
> So this is only different from what other build tools or whatever do. But
> it is well known behaviour, it is documented, and it can't be changed for
> backward compatibility anyway.
The only platform which this affects is Cygwin, we (the
On Sun, 2010-10-24 at 10:12 +0200, Hendrik Sattler wrote:
> And: believe it or not, WIN32 and CYGWIN are _not_ in strong contrast.
> They've
> got so much in common, starting from the binary file format to all low level
> stuff that cygwin is never going to change. Live with it.
The "low-level
--- Dom 24/10/10, Hendrik Sattler ha scritto:
> Am Sonntag 24 Oktober 2010, 08:37:30
> schrieb Marco Atzeri:
> > It should be changed. That will be the cleanest way
> for porting and
> > most of the time we will not need any IF (CYGWIN) to
> complete our job
> > as package maintainer.
> >
> > Ot
Am Sonntag 24 Oktober 2010, 08:37:30 schrieb Marco Atzeri:
> It should be changed. That will be the cleanest way for porting and
> most of the time we will not need any IF (CYGWIN) to complete our job
> as package maintainer.
>
> Othewise we should patch any sources to replace IF (WIN32) with
> IF
--- Ven 22/10/10, Rolf Eike Beer ha scritto:
> > This super-set is wrong. Cygwin belongs to Unix
> family
>
> Exactly. And guess what: "IF (UNIX)" would also include
> Cygwin.
>
> > I noticed. But Automake/autoconf makes it right, it
> > doesn't mix cygwin with win32 programs.
>
> Well, you di
>Are you using cygwin to try to make a native Windows port of a Unix
program, or are you simply trying to compile the Unix program as if it
was still Unix (and thereby trap it in the cygwin environment)?
>
> We have been used to people saying they want to build native Windows
apps with cygwin... an
--- Ven 22/10/10, David Cole ha scritto:
>This depends on your perspective. Are you using cygwin to try
> to make a native Windows port of a Unix program, or are you
> simply trying to compile the Unix program as if it was still
> Unix (and thereby trap it in the cygwin environment)?
My persp
> --- Ven 22/10/10, Michael Wild ha scritto:
>
>
>> >>
>> >> That's why one should check for CYGWIN in the
>> >> CMakeLists.txt files. IMHO this is a user-error
>> and not
>> >> CMake's fault. The doc clearly states about the
>> WIN32
>> >> variable:
>> >>
>> >>WIN32 True on
>> windows
>>
On Fri, Oct 22, 2010 at 5:37 AM, Marco Atzeri wrote:
> --- Ven 22/10/10, Michael Wild ha scritto:
>
> >
> > On 22. Oct, 2010, at 11:07 , Marco Atzeri wrote:
> >
> > > Dear developers,
> > > the current cmake package for cygwin is unsuitable to
> > build
> > > cmake package as it defines WIN32.
>
--- Ven 22/10/10, Michael Wild ha scritto:
> >>
> >> That's why one should check for CYGWIN in the
> >> CMakeLists.txt files. IMHO this is a user-error
> and not
> >> CMake's fault. The doc clearly states about the
> WIN32
> >> variable:
> >>
> >> WIN32 True on
> windows
> >> systems,
On 22. Oct, 2010, at 11:37 , Marco Atzeri wrote:
> --- Ven 22/10/10, Michael Wild ha scritto:
>
>>
>> On 22. Oct, 2010, at 11:07 , Marco Atzeri wrote:
>>
>>> Dear developers,
>>> the current cmake package for cygwin is unsuitable to
>> build
>>> cmake package as it defines WIN32.
>>> Cygwin p
--- Ven 22/10/10, Michael Wild ha scritto:
>
> On 22. Oct, 2010, at 11:07 , Marco Atzeri wrote:
>
> > Dear developers,
> > the current cmake package for cygwin is unsuitable to
> build
> > cmake package as it defines WIN32.
> > Cygwin programs are unix-like ones while WIN32 is
> needed only
> >
On 22. Oct, 2010, at 11:07 , Marco Atzeri wrote:
> Dear developers,
> the current cmake package for cygwin is unsuitable to build
> cmake package as it defines WIN32.
> Cygwin programs are unix-like ones while WIN32 is needed only
> for pure windows programs.
> Defining WIN32 breaks building nor
Dear developers,
the current cmake package for cygwin is unsuitable to build
cmake package as it defines WIN32.
Cygwin programs are unix-like ones while WIN32 is needed only
for pure windows programs.
Defining WIN32 breaks building normal unix programs.
To build the last qhull package
http://cygw
45 matches
Mail list logo
