On Wed, Jan 16, 2013 at 8:35 AM, Ruben Van Boxem wrote:
> I was under the strong impression all MSYS tools were built with a special
> (ancient) MSYS toolchain, which links and compiles in a Cygwin-y way. Maybe
> "goal" was stating it a bit strongly, but in how the MSYS devs saw their
> world takin
2013/1/16 Earnie Boyd
> On Wed, Jan 16, 2013 at 3:56 AM, Ruben Van Boxem
> wrote:
> > 2013/1/16 Ray Donnelly
> >>
> >> unixy utils built with Boost? Very cool. It'd be nice if an explicit
> >> goal was cross compilation on many different OSes.
> >>
> >> ...but why not pitch in with MSYS2 instea
2013/1/16 Earnie Boyd
> On Wed, Jan 16, 2013 at 8:18 AM, Vasileios Anagnostopoulos wrote:
> > UWIN anyone?
>
> No thanks, there are better alternatives that aren't closed source.
>
Starting with release 5.0, most of UWIN base package is available under the
EPL 1.0 (Eclipse Public License version
On Wed, Jan 16, 2013 at 8:18 AM, Vasileios Anagnostopoulos wrote:
> UWIN anyone?
No thanks, there are better alternatives that aren't closed source.
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
Master Java S
2013/1/16 Vasileios Anagnostopoulos
> UWIN anyone?
Wow, never ever before heard of this. This might be explained by the fact
their git repo shows the earlieast commit as 8 months ago. Seems like
something Cygwin-ish. Can't figure out how to install this simply though
(in the five minutes I've l
On Wed, Jan 16, 2013 at 3:56 AM, Ruben Van Boxem
wrote:
> 2013/1/16 Ray Donnelly
>>
>> unixy utils built with Boost? Very cool. It'd be nice if an explicit
>> goal was cross compilation on many different OSes.
>>
>> ...but why not pitch in with MSYS2 instead? Your time, your choice, of
>> course;
UWIN anyone?
On Wed, Jan 16, 2013 at 10:56 AM, Ruben Van Boxem
wrote:
> 2013/1/16 Ray Donnelly
>
>> unixy utils built with Boost? Very cool. It'd be nice if an explicit
>> goal was cross compilation on many different OSes.
>>
>> ...but why not pitch in with MSYS2 instead? Your time, your choice
2013/1/16 Ray Donnelly
> unixy utils built with Boost? Very cool. It'd be nice if an explicit
> goal was cross compilation on many different OSes.
>
> ...but why not pitch in with MSYS2 instead? Your time, your choice, of
> course; both are very worthy projects I think.
>
MSYS2 has a different i
unixy utils built with Boost? Very cool. It'd be nice if an explicit
goal was cross compilation on many different OSes.
...but why not pitch in with MSYS2 instead? Your time, your choice, of
course; both are very worthy projects I think.
On Wed, Jan 16, 2013 at 8:37 AM, Ruben Van Boxem
wrote:
>
2013/1/14 JonY
> On 1/14/2013 22:49, Ruben Van Boxem wrote:
> > That is of course a difficult one. Either internal bookkeeping or a
> simple
> > (?) translation function *where need be* (the hardest part being the
> latter
> > of course). MSYS achieves this somehow, so I'd start there.
> >
> >
>
On Mon, Jan 14, 2013 at 4:39 AM, Алексей Павлов wrote:
> Hey!
> Maybe fork new Cygwin to MSYS2 is the best solution? I am interesting in it
> because MSYS is very old and porting new software for it is very difficult.
> I can help you any way I can. I have Cygwin git repo on
> https://github.com/Al
On Mon, Jan 14, 2013 at 10:16 AM, JonY wrote:
>
> MSYS is pretty bad at path translation, it was what drove me to Cygwin
> in the first place. Perhaps some setting on how aggressive it scans and
> assumes a string as a path is a good idea.
>
> gcc -c abc.c -Dfoo="/bar1/bar2" <- is this a path to t
On 1/14/2013 22:49, Ruben Van Boxem wrote:
> That is of course a difficult one. Either internal bookkeeping or a simple
> (?) translation function *where need be* (the hardest part being the latter
> of course). MSYS achieves this somehow, so I'd start there.
>
>
MSYS is pretty bad at path trans
2013/1/14 JonY
> On 1/14/2013 20:59, Ruben Van Boxem wrote:
> >>
> >> But seriously, you will probably end up writing your own PE loader to
> >> simulate fork(), since specs say new process must have exact memory
> >> layout as the parent, not to mention Posix signaling pipelines to route
> >> to
On 1/14/2013 20:59, Ruben Van Boxem wrote:
>>
>> But seriously, you will probably end up writing your own PE loader to
>> simulate fork(), since specs say new process must have exact memory
>> layout as the parent, not to mention Posix signaling pipelines to route
>> to the correct process. fork()
2013/1/14 Алексей Павлов
> Hey!
> Maybe fork new Cygwin to MSYS2 is the best solution? I am interesting in
> it because MSYS is very old and porting new software for it is very
> difficult. I can help you any way I can. I have Cygwin git repo on
> https://github.com/Alexpux/Cygwin.git ерфе I sync
2013/1/14 JonY
> On 1/14/2013 17:29, Ruben Van Boxem wrote:
> > Hey guys,
> >
> > I couldn't sleep last night and thought of this: MSYS is a fork of
> Cygwin,
> > which introduced a bunch of POSIX runtime stuff to be able to run all
> them
> > shell commands.
> >
> > What if someone were to write
On 1/14/2013 17:29, Ruben Van Boxem wrote:
> Hey guys,
>
> I couldn't sleep last night and thought of this: MSYS is a fork of Cygwin,
> which introduced a bunch of POSIX runtime stuff to be able to run all them
> shell commands.
>
> What if someone were to write an sh interpreter that used specia
Hey!
Maybe fork new Cygwin to MSYS2 is the best solution? I am interesting in it
because MSYS is very old and porting new software for it is very
difficult. I can help you any way I can. I have Cygwin git repo on
https://github.com/Alexpux/Cygwin.git ерфе I synchronizes once a week with
Cygwin cvs
Hey guys,
I couldn't sleep last night and thought of this: MSYS is a fork of Cygwin,
which introduced a bunch of POSIX runtime stuff to be able to run all them
shell commands.
What if someone were to write an sh interpreter that used special tricks to
manipulate directory names when it calls prog
20 matches
Mail list logo
