More GitHub Mirrors

[Daniel Cassidy]

Hi all,

I created automated Git mirrors of various Haxe projects for my own use, and I thought I might as well put them where other people can see them: https://github.com/haxe-mirrors

I realise this is largely redundant work as there are existing Git mirrors for most of these projects, but I wasn’t satisfied with the mirrors I could find for various reasons. I’ve tried to get my mirrors into as good a state as possible, so that they would be suitable for use immediately should any of these projects decide to switch to git, hint hint ;).

The mirror for Haxe itself is at https://github.com/haxe-mirrors/haxe

This is very similar to Philipp Klose’s (TheHippo) mirror, in that it tracks not only Haxe itself but also ocamllibs and the install.ml script, and merges them all into a single repository that should allow anyone to build out-of-the-box (provided that they have installed git and OCaml and a C compiler and, for non-Windows platforms, zlib).

I did try to use Philipp’s mirror but his install.ml didn’t work on Windows, and his ocamllibs was still tracking CVS, and missing some files required on Windows that he seems to have gitignored by mistake. I tried to get it into working order, but he has checked in install.ml and ocamllibs pre-modified, so I found it hard to distinguish intentional changes from differences in the version he started with. In the end I gave up and started from scratch. That’s probably more my fault than his.

My mirror tracks the complete, unmodified history of its component parts in separate branches so you can always do a diff to see what I’ve changed compared to vanilla (just install.ml, README.md and .gitignore).

You should be able to clone it and compile out-of-the-box with ocaml install.ml. I’ve tested it on Windows and Ubuntu. I will test it on OSX shortly.

The README contains building instructions that I think are more up-to-date and certainly more straightforward than the ones on the Haxe wiki, so I will update the Haxe wiki with similar instructions for SVN users unless someone thinks I’ve got it wrong.

My other mirrors just track their respective SVN repositories with no special changes.

For all of the mirrors I’ve tried to match up SVN usernames with developer’s real names and email addresses so that all git commits are properly attributed, and match up to developer’s GitHub accounts where they exist. I’ve only done that where developers are clearly publicly associated with the project, though (e.g. they’ve clearly identified themselves on corresponding mailing lists, or they commit to SVN using their real names or email addresses as an SVN username). I’m not in the business of invading people’s privacy, so where developers have made a clear effort to remain anonymous or pseudonymous, I’ve respected that.

I’ve also noticed that some of the existing mirrors update annoyingly infrequently. Mine update every hour. It did occur to me that this might be to avoid hammering the SVN servers, but then the amount of data transferred is the same either way, and so far all of these repositories are on Google Code, which can certainly handle it :).

Anyway, if you think this is useful, or useless, or something is broken, or someone would like me to add more mirrors, or anyone is particularly offended by what I’m doing, let me know.

Dan.

[Simon Krajewski]

Am 17.07.2012 18:53, schrieb Daniel Cassidy:
> Hi all,
>
> I created automated Git mirrors of various Haxe projects for my own
> use, and I thought I might as well put them where other people can see
> them: https://github.com/haxe-mirrors
>
> I realise this is largely redundant work as there are existing Git

> mirrors for most of these projects, but I wasn�t satisfied with the
> mirrors I could find for various reasons. I�ve tried to get my mirrors

> into as good a state as possible, so that they would be suitable for
> use immediately should any of these projects decide to switch to git,
> hint hint ;).
>
>
> The mirror for Haxe itself is at https://github.com/haxe-mirrors/haxe
>

> This is very similar to Philipp Klose�s (TheHippo) mirror, in that it

> tracks not only Haxe itself but also ocamllibs and the install.ml
> script, and merges them all into a single repository that should allow
> anyone to build out-of-the-box (provided that they have installed git
> and OCaml and a C compiler and, for non-Windows platforms, zlib).
>

> I did try to use Philipp�s mirror but his install.ml didn�t work on

> Windows, and his ocamllibs was still tracking CVS, and missing some
> files required on Windows that he seems to have gitignored by mistake.
> I tried to get it into working order, but he has checked in install.ml
> and ocamllibs pre-modified, so I found it hard to distinguish
> intentional changes from differences in the version he started with.

> In the end I gave up and started from scratch. That�s probably more my

> fault than his.
>
> My mirror tracks the complete, unmodified history of its component
> parts in separate branches so you can always do a diff to see what

> I�ve changed compared to vanilla (just install.ml, README.md and

> .gitignore).
>
> You should be able to clone it and compile out-of-the-box with ocaml

> install.ml. I�ve tested it on Windows and Ubuntu. I will test it on

> OSX shortly.
>
> The README contains building instructions that I think are more
> up-to-date and certainly more straightforward than the ones on the
> Haxe wiki, so I will update the Haxe wiki with similar instructions

> for SVN users unless someone thinks I�ve got it wrong.

>
>
> My other mirrors just track their respective SVN repositories with no
> special changes.
>

> For all of the mirrors I�ve tried to match up SVN usernames with
> developer�s real names and email addresses so that all git commits are
> properly attributed, and match up to developer�s GitHub accounts where
> they exist. I�ve only done that where developers are clearly publicly
> associated with the project, though (e.g. they�ve clearly identified

> themselves on corresponding mailing lists, or they commit to SVN using

> their real names or email addresses as an SVN username). I�m not in
> the business of invading people�s privacy, so where developers have
> made a clear effort to remain anonymous or pseudonymous, I�ve
> respected that.
>
> I�ve also noticed that some of the existing mirrors update annoyingly

> infrequently. Mine update every hour. It did occur to me that this
> might be to avoid hammering the SVN servers, but then the amount of
> data transferred is the same either way, and so far all of these
> repositories are on Google Code, which can certainly handle it :).
>
>
> Anyway, if you think this is useful, or useless, or something is
> broken, or someone would like me to add more mirrors, or anyone is

> particularly offended by what I�m doing, let me know.

On that note I would like to mention that haxelib supports git now, so
you can for example do
haxelib git tink https://github.com/back2dos/tinkerbell src
in order to install a tink library which draws its sources from the
given github project (+ src subdirectory).

Example for the hxformat mirror:
haxelib git format https://github.com/haxe-mirrors/hxformat

haxelib upgrade will also check git repositories and automatically pull
newer versions if available.

Simon

[Andy Li]

FYI, there is an NME mirror on github that support two-way sync now:

https://github.com/jgranick/NME

Joshua've already merged 2 pull requests from me and the svn repo is synced correctly ;)

Cheers,

Andy

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
 
 
 

[Andreas Mokros]

Hi.

On Tue, 17 Jul 2012 09:53:53 -0700 (PDT)
Daniel Cassidy <ma...@danielcassidy.me.uk> wrote:
> The README contains building instructions that I think are more
> up-to-date and certainly more straightforward than the ones on the
> Haxe wiki, so I will update the Haxe wiki with similar instructions

> for SVN users unless someone thinks I�ve got it wrong.

OK, then:

<quote>
A modified copy of install.ml, the Haxe build script, which is for some
strange reason maintained outside the Haxe SVN repository (modified to
work with this git mirror, since the original script is dependent on
SVN).
</quote>

1. install.ml can be found in /doc in SVN
2. install.ml is not needed anymore. You should use the Makefile
instead (since 2.09+).

--
Mockey

[Daniel Cassidy]

Ah, marvellous. I’ll take the NME mirror down then.

Is that new? I didn’t see it when I first set stuff up but that was a few weeks ago.

Dan

[Daniel Cassidy]

Ahah, thanks. The advice on the wiki is worse than I thought, then. But I’m rather relieved to hear that there is a real build script in the official repository now.

I will update my mirror and the wiki in a few hours.

[Andy Li]

Yes it is new. It has been public for a few days only.

Cheers,

Andy

[Philipp Klose]

I'm aware that my respository is not up to date anymore. The install.ml
was replaced by a Makefile and the ocaml libs are not an csv repository
anymore. I need to update the whole process how this repository is managed.

Am 17.07.2012 18:53, schrieb Daniel Cassidy:

> Hi all,
>
> I created automated Git mirrors of various Haxe projects for my own
> use, and I thought I might as well put them where other people can see
> them: https://github.com/haxe-mirrors
>
> I realise this is largely redundant work as there are existing Git

> mirrors for most of these projects, but I wasn�t satisfied with the
> mirrors I could find for various reasons. I�ve tried to get my mirrors

> into as good a state as possible, so that they would be suitable for
> use immediately should any of these projects decide to switch to git,
> hint hint ;).
>
>
> The mirror for Haxe itself is at https://github.com/haxe-mirrors/haxe
>

> This is very similar to Philipp Klose�s (TheHippo) mirror, in that it

> tracks not only Haxe itself but also ocamllibs and the install.ml
> script, and merges them all into a single repository that should allow
> anyone to build out-of-the-box (provided that they have installed git
> and OCaml and a C compiler and, for non-Windows platforms, zlib).
>

> I did try to use Philipp�s mirror but his install.ml didn�t work on

> Windows, and his ocamllibs was still tracking CVS, and missing some
> files required on Windows that he seems to have gitignored by mistake.
> I tried to get it into working order, but he has checked in install.ml
> and ocamllibs pre-modified, so I found it hard to distinguish
> intentional changes from differences in the version he started with.

> In the end I gave up and started from scratch. That�s probably more my

> fault than his.
>
> My mirror tracks the complete, unmodified history of its component
> parts in separate branches so you can always do a diff to see what

> I�ve changed compared to vanilla (just install.ml, README.md and

> .gitignore).
>
> You should be able to clone it and compile out-of-the-box with ocaml

> install.ml. I�ve tested it on Windows and Ubuntu. I will test it on

> OSX shortly.
>
> The README contains building instructions that I think are more
> up-to-date and certainly more straightforward than the ones on the
> Haxe wiki, so I will update the Haxe wiki with similar instructions

> for SVN users unless someone thinks I�ve got it wrong.

>
>
> My other mirrors just track their respective SVN repositories with no
> special changes.
>

> For all of the mirrors I�ve tried to match up SVN usernames with
> developer�s real names and email addresses so that all git commits are
> properly attributed, and match up to developer�s GitHub accounts where
> they exist. I�ve only done that where developers are clearly publicly
> associated with the project, though (e.g. they�ve clearly identified

> themselves on corresponding mailing lists, or they commit to SVN using

> their real names or email addresses as an SVN username). I�m not in
> the business of invading people�s privacy, so where developers have
> made a clear effort to remain anonymous or pseudonymous, I�ve
> respected that.
>

> I�ve also noticed that some of the existing mirrors update annoyingly

> infrequently. Mine update every hour. It did occur to me that this
> might be to avoid hammering the SVN servers, but then the amount of
> data transferred is the same either way, and so far all of these
> repositories are on Google Code, which can certainly handle it :).
>
>
> Anyway, if you think this is useful, or useless, or something is
> broken, or someone would like me to add more mirrors, or anyone is

> particularly offended by what I�m doing, let me know.
>
> Dan.

[Philipp Klose]

Also I think compiling haxe now should be triggered with a make command
instead of the "ocaml install.ml" call.

Am 17.07.2012 18:53, schrieb Daniel Cassidy:

> Hi all,
>
> I created automated Git mirrors of various Haxe projects for my own
> use, and I thought I might as well put them where other people can see
> them: https://github.com/haxe-mirrors
>
> I realise this is largely redundant work as there are existing Git

> mirrors for most of these projects, but I wasn�t satisfied with the
> mirrors I could find for various reasons. I�ve tried to get my mirrors

> into as good a state as possible, so that they would be suitable for
> use immediately should any of these projects decide to switch to git,
> hint hint ;).
>
>
> The mirror for Haxe itself is at https://github.com/haxe-mirrors/haxe
>

> This is very similar to Philipp Klose�s (TheHippo) mirror, in that it

> tracks not only Haxe itself but also ocamllibs and the install.ml
> script, and merges them all into a single repository that should allow
> anyone to build out-of-the-box (provided that they have installed git
> and OCaml and a C compiler and, for non-Windows platforms, zlib).
>

> I did try to use Philipp�s mirror but his install.ml didn�t work on

> Windows, and his ocamllibs was still tracking CVS, and missing some
> files required on Windows that he seems to have gitignored by mistake.
> I tried to get it into working order, but he has checked in install.ml
> and ocamllibs pre-modified, so I found it hard to distinguish
> intentional changes from differences in the version he started with.

> In the end I gave up and started from scratch. That�s probably more my

> fault than his.
>
> My mirror tracks the complete, unmodified history of its component
> parts in separate branches so you can always do a diff to see what

> I�ve changed compared to vanilla (just install.ml, README.md and

> .gitignore).
>
> You should be able to clone it and compile out-of-the-box with ocaml

> install.ml. I�ve tested it on Windows and Ubuntu. I will test it on

> OSX shortly.
>
> The README contains building instructions that I think are more
> up-to-date and certainly more straightforward than the ones on the
> Haxe wiki, so I will update the Haxe wiki with similar instructions

> for SVN users unless someone thinks I�ve got it wrong.

>
>
> My other mirrors just track their respective SVN repositories with no
> special changes.
>

> For all of the mirrors I�ve tried to match up SVN usernames with
> developer�s real names and email addresses so that all git commits are
> properly attributed, and match up to developer�s GitHub accounts where
> they exist. I�ve only done that where developers are clearly publicly
> associated with the project, though (e.g. they�ve clearly identified

> themselves on corresponding mailing lists, or they commit to SVN using

> their real names or email addresses as an SVN username). I�m not in
> the business of invading people�s privacy, so where developers have
> made a clear effort to remain anonymous or pseudonymous, I�ve
> respected that.
>

> I�ve also noticed that some of the existing mirrors update annoyingly

> infrequently. Mine update every hour. It did occur to me that this
> might be to avoid hammering the SVN servers, but then the amount of
> data transferred is the same either way, and so far all of these
> repositories are on Google Code, which can certainly handle it :).
>
>
> Anyway, if you think this is useful, or useless, or something is
> broken, or someone would like me to add more mirrors, or anyone is

> particularly offended by what I�m doing, let me know.
>
> Dan.

[Daniel Cassidy]

Assuming that the devs using your repository don’t want to just switch to mine (which does seem quite probable, to be honest), and that you’re willing and able, I’d be quite happy to give you a hand getting it back in order.

The only reason I started again is because I found myself retracing most of your steps anyway :).

Dan.

[Daniel Cassidy]

Yup, you’re right. I didn’t notice the new Makefile amongst all the other stuff in the root, and I foolishly assumed that the wiki was moderately up to date :).

I’ll fix that in the next few hours.

Dan.

[Zachary Dremann]

The main thing I'd say is to try using git submodules for ocamllibs. I have one set up here, actually https://github.com/Dr-Emann/haxe, that does that. 

[Daniel Cassidy]

I’m extremely dubious about the utility of git submodules. In most cases it just feels like a way to make life much more complicated without any real benefit.

I much prefer to just track the submodule in a branch, and then regularly merge that branch in to master with the subtree merge strategy. I’ve still got a clean history of ocamllibs in ocamllibs/master, which could theoretically be pushed into a separate repository without any contamination from haxe, if someone saw a need. If it’s good enough for Linus to merge gitk into git, it’s good enough for me ;).

Dan

[Andreas Mokros]

Hi.

On Tue, 17 Jul 2012 10:38:44 -0700 (PDT)
Daniel Cassidy <ma...@danielcassidy.me.uk> wrote:
> Ahah, thanks. The advice on the wiki is worse than I thought, then.

Yeah, well, the wiki...

> But I�m rather relieved to hear that there is a real build script in
> the official repository now.

I can only confirm that it builds fine on Linux, though. Haven't tried
to compile on OSX nor the Makefile.win on Windows...

> I will update my mirror *and* the wiki in a few hours.

That's great.

--
Mockey

[Daniel Cassidy]

On Tuesday, 17 July 2012 19:40:16 UTC+1, Andreas Mokros wrote:

I can only confirm that it builds fine on Linux, though. Haven't tried
to compile on OSX nor the Makefile.win on Windows...

Short answer: The Makefile doesn’t work on Windows. I will leave the slightly-modified install.ml in place for now, but update the README to instruct Linux users to use the Makefile.

Longer answer:

I got most of the way through the build process by using this build of OCaml/MinGW 4.00.0, and the Cygwin + MinGW concoction that it installs for you, although it’s necessary to patch Haxe for compatibility with OCaml 4. The build stopped because zlib was missing. It should be possible to get all the way through by compiling zlib with MinGW, but compiling and installing libraries for MinGW under Cygwin is, from past experience, an infuriatingly error-prone process (it’s effectively a cross-compile), so I stopped there.

Don’t even think about using OCaml/MinGW 3.12.1 because that will wipe out your PATH, system wide, leading to hours of fun fixing every other command-line tool on your system.

Older releases of OCaml/MinGW don’t install Cygwin for you. It appears that it might be possible to use an old release of OCaml/MinGW in conjunction with an install of MSYS. I’m tempted to give this a try but if I write instructions involving MSYS, they are going to be short-lived giving that the current maintainer of OCaml/MinGW seems to be pushing users to use Cygwin instead.

There is apparently some combination of tools that makes it possible to build with OCaml/MSVC using make MSVC=1 -f Makefile.win, but I’m unable to fathom exactly what it is. I fear that it involves having MSYS/Cygwin and MSVC in your PATH at the same time which, from past experience, is a recipe for serious pain.

So long as install.ml is up to date it feels to me like a better option on Windows. The process to get it working is less complicated and more reliable. If I’m missing some obvious combination of reliable tools that does the job of getting the Makefile to work, I would be most obliged if someone would let me know what it is.

Dan.

[Andreas Mokros]

Hi.

On Tue, 17 Jul 2012 13:27:26 -0700 (PDT)
Daniel Cassidy <ma...@danielcassidy.me.uk> wrote:
> Don�t even think about using OCaml/MinGW 3.12.1 because that will
> wipe out your PATH
> <https://github.com/protz/ocaml-installer/issues/1>, system wide,

> leading to hours of fun fixing every other command-line tool on your
> system.

Did that really wipe out your PATH?

> There is apparently some combination of tools that makes it possible

> to build with OCaml/MSVC using make MSVC=1 -f Makefile.win, but I�m

> unable to fathom exactly what it is. I fear that it involves having
> MSYS/Cygwin and MSVC in your PATH at the same time which, from past
> experience, is a recipe for serious pain.

I think Nicolas and most (if not all) developers compile under Windows.
What do they use?

--
Mockey

[Daniel Cassidy]

On 17 July 2012 22:36, Andreas Mokros <m...@medienpensionat.com> wrote:

On Tue, 17 Jul 2012 13:27:26 -0700 (PDT)
Daniel Cassidy <ma...@danielcassidy.me.uk> wrote:

> Don’t even think about using OCaml/MinGW 3.12.1 because that will
> wipe out your PATH

> <https://github.com/protz/ocaml-installer/issues/1>, system wide,

> leading to hours of fun fixing every other command-line tool on your
> system.

Did that really wipe out your PATH?

Yup! Replaced it in its entirety with just the path to OCaml. I was not best pleased! Apparently due to a limitation in NSIS. It only affects you if your path is over a certain length to start with, though – the developer claims 1024 characters although I’m not at all convinced that mine was really that long. Of course, that just means it only affects those with the most to lose.

 

> There is apparently some combination of tools that makes it possible

> to build with OCaml/MSVC using make MSVC=1 -f Makefile.win, but I’m

> unable to fathom exactly what it is. I fear that it involves having
> MSYS/Cygwin and MSVC in your PATH at the same time which, from past
> experience, is a recipe for serious pain.

I think Nicolas and most (if not all) developers compile under Windows.
What do they use?

That’s what I’m wondering! :)

[Jan_Flanders]

On Tuesday, July 17, 2012 11:46:27 PM UTC+2, Daniel Cassidy wrote:

On 17 July 2012 22:36, Andreas Mokros  wrote:

Did that really wipe out your PATH?

 Apparently due to a limitation in NSIS.

1)
There is a special build where this 'bug' is fixed : http://forums.winamp.com/showpost.php?s=9a0a01fcef1b1b983e9c3e8e4d41707c&p=2573484&postcount=2
(That was my topic btw. Since that time I always backup my PATH before I let any (installer) script touch it. :p )

2)
I added your github mirror to the download page in the wiki: http://haxe.org/download#building-from-source

3)
A bit off topic: It would be nice if someone, who has English as mother tongue, could write a better tutorial than the current one for using 'make' to build haxe from source:
http://haxe.org/download/make

Cheers,

Jan

[Greg Dove]

fwiw I am using Ocaml MinGW 3.12.1 and have been for months. I must have had a path under the limit when I set up, because I didn't experience that (fortunately). 

Otherwise I can build fine with install.ml and the resulting haxe.exe works fine. I have only recently encountered one problem with the install.ml build: http://code.google.com/p/haxe/issues/detail?id=1058

However I don't have the same sucess with make. Although make works for me without errors, the haxe.exe created with make crashes when I use it (it is not the same size as haxe.exe built using install.ml). This was uncharted territory for me so the cause is far from obvious to me so far.

--

[Daniel Cassidy]

Hi Greg,

On Tuesday, 17 July 2012 23:12:14 UTC+1, Greg Dove wrote:

However I don't have the same sucess with make. Although make works for me without errors, the haxe.exe created with make crashes when I use it (it is not the same size as haxe.exe built using install.ml). This was uncharted territory for me so the cause is far from obvious to me so far.

In spite of your lack of success I’d still be interested to know what you did to get that far. Are you using the make from Cygwin, or MSYS, or somewhere else? Did you compile zlib manually or install binaries from somewhere?

Any information appreciated!

Dan. 

[Greg Dove]

From memory I think I just followed the original MinGW instructions here : http://haxe.org/doc/build/haxe_windows. I remember stumbling my way through things at the start. I may have had to do some other things to get stuff working, but if I did, I can't recall the details, sorry. 

I'm attaching my install.ml in case that is any help. I think I made some changes beyond those outlined in the instructions (if they don't seem to make sense, that would be a direct reflection of my knowledge!)

For make,  think/assume that is the make from msys (maybe that is part of my problem there?, like I said, "uncharted territory" for me)

--

[Daniel Cassidy]

More things I have learned:

• OCaml/MSVC 3.09.0 works with install.ml, but OCaml/MSVC 3.11.0 complains about missing flexlink.exe when running ocamlopt.
  
• Recent versions of OCaml/MinGW don’t work with recent versions of MinGW because they insist on passing -mno-cygwin to gcc, which is only accepted by Cygwin builds of gcc. You can’t make it up.

OCaml on Windows is a dispiriting mess :(.

[John Plsek]

Install Flexlink - as per "Build Haxe on Windows" instructions - http://haxe.org/doc/build/haxe_windows

problem solved

John

[Daniel Cassidy]

On Wednesday, 18 July 2012 02:06:40 UTC+1, jaromanda wrote:

Install Flexlink - as per "Build Haxe on Windows" instructions - http://haxe.org/doc/build/haxe_windows

Yes, I can see how to fix it and maybe I should have mentioned that. My point was that the packaging of OCaml for Windows is wildly inconsistent.

I was going to try to clean up the build instructions, but it seems pointless when they’re obsoleted and/or complicated by every new release and variant of OCaml. To put it another way, I see now why the instructions are such a mess of conflicting suggestions.

(You don’t actually need Flexlink if you download the version of OCaml that’s linked from the instructions, for example.)

[Andreas Mokros]

Hi.

On Tue, 17 Jul 2012 15:03:44 -0700 (PDT)
Jan_Flanders <adn...@gmail.com> wrote:
> There is a special build where this 'bug' is fixed :

What setup do you use for your Windows nightly?

--
Mockey

[Andreas Mokros]

Hi.

On Tue, 17 Jul 2012 17:13:44 -0700 (PDT)
Daniel Cassidy <ma...@danielcassidy.me.uk> wrote:
> - OCaml/MSVC 3.09.0 works with install.ml, but OCaml/MSVC 3.11.0

> complains about missing flexlink.exe when running ocamlopt.

I remember running into that problem long ago when I tried compiling
under Windows.

> OCaml on Windows is a dispiriting mess :(.

So again: What setup do the developers (Nicolas/Caue/Simon/...) use for
building under Windows? Maybe ask in a new thread?

--
Mockey

[Simon Krajewski]

I'm using MSVC, so what I have is:
- MSVC
- OCaml 3.11
(http://caml.inria.fr/pub/distrib/ocaml-3.11/ocaml-3.11.0-win-msvc.exe)
- Flexlink
- SVN

I think that's it. To build I run vcvarsall.bat and then make MSVC=1 -j4
-f Makefile.win haxe

Simon

[Nicolas Cannasse]

Le 18/07/2012 09:08, Andreas Mokros a �crit :

I'm using Ocaml 3.10/MSVC, it does not seem to require flexlink.

And yes I agree since 3.09, OCaml Windows support has been quite down. I
think there's even no longer MSVC builds for 3.12. But if you have a gnu
toolchain (make etc) then recompiling from sources is not that hard.
Windows users are not used that much to do so, but Linux users usually
do recompile - almost - everything ;)

Best,
Nicolas

[Edu García]

On Mac, the official Makefile sort of works. "Sort of", because if the makefile is interrupted because any error and you try to do "make" again, you get funny errors that are fixed doing a clean and starting again. Don't know if that's the normal way of working :P

[Andreas Mokros]

Hi.

On Wed, 18 Jul 2012 09:13:09 +0200
Simon Krajewski <simon.k...@simn.de> wrote:
> - MSVC

Which version?

> To build I run vcvarsall.bat

That's the Visual Studio Command Prompt, right?

> and then make MSVC=1 -j4 -f Makefile.win haxe

Uhm, make runs there or do you have Cygwin installed?

--
Mockey

[Simon Krajewski]

Am 18.07.2012 09:25, schrieb Andreas Mokros:
> Hi.
>
> On Wed, 18 Jul 2012 09:13:09 +0200
> Simon Krajewski <simon.k...@simn.de> wrote:
>> - MSVC
> Which version?

I've been through multiple versions, it shouldn't matter.

>> To build I run vcvarsall.bat
> That's the Visual Studio Command Prompt, right?

It sets up the environment when the VS command prompt is run, but you
can also just run the batch file from normal command line if you prefer.

>> and then make MSVC=1 -j4 -f Makefile.win haxe
> Uhm, make runs there or do you have Cygwin installed?

Ah yes, I have GnuWin32 installed:
http://gnuwin32.sourceforge.net/packages/make.htm
I also have cygwin installed and its bin in the PATH.

Simon

[Andreas Mokros]

Hi.

On Wed, 18 Jul 2012 09:41:46 +0200
Simon Krajewski <simon.k...@simn.de> wrote:
> I also have cygwin installed and its bin in the PATH.

OK, thanks for the infos.

--
Mockey

[Jan_Flanders]

I'm still using the install.ml ( http://haxe.org/doc/build/haxe_windows#visualc ) but I'm going to try cygwin today.

Jan

PS: My remark about 'the special build' was about NSIS btw.

[Daniel Cassidy]

On Wednesday, 18 July 2012 08:41:46 UTC+1, Simon Krajewski wrote:

>> and then make MSVC=1 -j4 -f Makefile.win haxe
> Uhm, make runs there or do you have Cygwin installed?

Ah yes, I have GnuWin32 installed:
http://gnuwin32.sourceforge.net/packages/make.htm
I also have cygwin installed and its bin in the PATH.

Assuming that you mean you have Cygwin in the global PATH, be warned that the Cygwin guys don’t recommend it, and that you might be in for some trouble. In particular you risk breaking any application that uses its own cygwin1.dll under the hood (and many do), and it won’t be some obvious breakage with an obvious cause, you’ll be in for a long night of head-scratching.

There are also common issues with Cygwin commands conflicting with standard Windows commands, and no matter which order you put them in the path, something breaks because each environment (quite reasonably) expects to be first in the PATH.

It shouldn’t hurt to bring Cygwin into the PATH for the duration of a single command prompt just to build Haxe, though.

Dan.

[Daniel Cassidy]

On Wednesday, 18 July 2012 08:16:30 UTC+1, Nicolas Cannasse wrote:

And yes I agree since 3.09, OCaml Windows support has been quite down. I
think there's even no longer MSVC builds for 3.12. But if you have a gnu
toolchain (make etc) then recompiling from sources is not that hard.
Windows users are not used that much to do so, but Linux users usually
do recompile - almost - everything ;) 

Yes, that is starting to look like the better option.

I’m usually happy to tweak and recompile stuff if it’s not working for me, but recompiling the compiler for my compiler starts to feel a bit silly unless it’s absolutely necessary :).

Dan.

[Jan_Flanders]

On Wednesday, July 18, 2012 2:41:49 PM UTC+2, Jan_Flanders wrote:

 I'm going to try cygwin today.

Building haxe with 'make' in Cygwin works fine but the executable is not only double the size of the one being built with install.ml, it can also only be used by people that have Cygwin installed or its bin folder in PATH. Otherwise you get the error listed at the bottom here: http://haxe.org/doc/build/haxe_windows#cygwin
I don't understand how this can serve as a 'public' nightly build for example.

Jan

[Simon Krajewski]

Well I'm not building with Cygwin, I just noticed that I have it in the path (I didn't put it there for haxe compilation). I just tried removing it an ran into an compilation error due to sed not found, but after resolving that otherwise it compiles just fine. So no Cygwin needed.

Simon

[Simon Krajewski]

I have to make a small correction: While it's true that I can use make haxe without a problem, I run into problems when trying to make all or make libs:

(cd libs/extlib; make opt)
process_begin: CreateProcess(NULL, (cd libs/extlib; make opt), ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [libs] Error 2

I'll try to figure out what's the problem here.

Simon

[Daniel Cassidy]

On Thursday, 19 July 2012 13:11:11 UTC+1, Simon Krajewski wrote:

I have to make a small correction: While it's true that I can use make haxe without a problem, I run into problems when trying to make all or make libs:

(cd libs/extlib; make opt)
process_begin: CreateProcess(NULL, (cd libs/extlib; make opt), ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [libs] Error 2

Presumably you must be using the GNU Make from GNUWin32.

The problem is that it can’t instantiate a subshell to execute the commands (cd libs/extlib; make opt).

I can’t see this ever working because the concept “instantiate a subshell” doesn’t make much sense on Windows.

I don’t think Makefiles are a very good way to build on Windows. I think there was much more mileage in having a build script written in OCaml, since you need OCaml to build anyway, and it provides a relatively consistent environment on every platform.

The only real issue I can see with install.ml is that it insists on checking out from svn inside the build script, which doesn’t make much sense if you’ve already checked out. Also, it doesn’t build haxelib and haxedoc. But both of those things are very easy to fix.

Dan.

[Daniel Cassidy]

On Thursday, 19 July 2012 14:13:23 UTC+1, Daniel Cassidy wrote:

Presumably you must be using the GNU Make from GNUWin32.

The problem is that it can’t instantiate a subshell to execute the commands (cd libs/extlib; make opt).

I can’t see this ever working because the concept “instantiate a subshell” doesn’t make much sense on Windows.

Self-correction: I phrased that very poorly. Make just passes the whole command line to a shell, which in Windows is cmd.exe. In Bourne-derived shells, the construct “( ... )” means “instantiate a subshell and run these commands in the subshell”. But there’s no equivalent construct in cmd.exe, so it can’t work.

Dan.

[Simon Krajewski]

Am 19.07.2012 15:13, schrieb Daniel Cassidy:

On Thursday, 19 July 2012 13:11:11 UTC+1, Simon Krajewski wrote:

I have to make a small correction: While it's true that I can use make haxe without a problem, I run into problems when trying to make all or make libs:

(cd libs/extlib; make opt)
process_begin: CreateProcess(NULL, (cd libs/extlib; make opt), ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [libs] Error 2

Presumably you must be using the GNU Make from GNUWin32.

The problem is that it can�t instantiate a subshell to execute the commands (cd libs/extlib; make opt).

I can�t see this ever working because the concept �instantiate a subshell� doesn�t make much sense on Windows.

I don�t think Makefiles are a very good way to build on Windows. I think there was much more mileage in having a build script written in OCaml, since you need OCaml to build anyway, and it provides a relatively consistent environment on every platform.

The only real issue I can see with install.ml is that it insists on checking out from svn inside the build script, which doesn�t make much sense if you�ve already checked out. Also, it doesn�t build haxelib and haxedoc. But both of those things are very easy to fix.

Yes, I use GnuWin32. I could work around the problem on windows by doing
��� make -C libs/extlib opt
instead, which seems cleaner anyway. Building the libs works now with current makefile, but I'll have to check the tools and also clean.

Since you seem to know a lot about these things, maybe you can help me with this problem on clean_libs:

make -C libs/extlib clean
make[1]: Entering directory `C:/Motion-Twin/haxesvn/libs/extlib'
rm -f *.cmo *.cmx *.o *.cmi *.cma *.cmxa *.a *.lib *.obj
rm: Entfernen von "*.cmo" nicht m�glich: Invalid argument
rm: Entfernen von "*.cmx" nicht m�glich: Invalid argument
rm: Entfernen von "*.o" nicht m�glich: Invalid argument

It says that removing is not possible and that causes the make process to stop. I thought -f would make it ignore that, but apparently that doesn't work here. Any idea why it behaves like that?

Simon

[Daniel Cassidy]

On Thursday, 19 July 2012 14:20:38 UTC+1, Simon Krajewski wrote:

Since you seem to know a lot about these things, maybe you can help me with this problem on clean_libs:

make -C libs/extlib clean
make[1]: Entering directory `C:/Motion-Twin/haxesvn/libs/extlib'
rm -f *.cmo *.cmx *.o *.cmi *.cma *.cmxa *.a *.lib *.obj
rm: Entfernen von "*.cmo" nicht m�glich: Invalid argument
rm: Entfernen von "*.cmx" nicht m�glich: Invalid argument
rm: Entfernen von "*.o" nicht m�glich: Invalid argument

It says that removing is not possible and that causes the make process to stop. I thought -f would make it ignore that, but apparently that doesn't work here. Any idea why it behaves like that?

"-f" does indeed ignore file-not-found errors, but what you're seeing is actually an invalid filename error.

In Windows, glob expansion is performed by the executable (in this case rm.exe), but in Unix it is performed by the shell. For this reason, GNUWin32 tools include some compatibility magic that performs shell-style glob expansion before the program entry point. In this way, everything works (nearly) as you expect.

In Bourne-derived shells, if a glob doesn't match any files, then it expands to itself. GNUWin32 emulates this behaviour. So, if there is no file matching "*.cmo", the string "*.cmo" will be passed literally to rm and rm will try to delete a file with that name.

The problem is that the character "*" is not legal for filenames in Windows, so when rm tries to delete the file, Windows complains and rm dies.

You could work round it by ensuring that at least one file matching each glob exists before running rm:

touch foo.cmo foo.cmx foo.o foo.cmi foo.cma foo.cmxa foo.a foo.lib foo.obj

rm -f *.cmo *.cmx *.o *.cmi *.cma *.cmxa *.a *.lib *.obj

but that's messy.

The other option is to pass a list of filenames to rm instead of globs. It should be possible to get make to expand a list of object files from the list of source files.

But it all feels terribly fragile to me :(.

Dan.

[Daniel Cassidy]

On Thursday, 19 July 2012 15:20:17 UTC+1, Daniel Cassidy wrote:

In Bourne-derived shells, if a glob doesn't match any files, then it expands to itself. GNUWin32 emulates this behaviour. So, if there is no file matching "*.cmo", the string "*.cmo" will be passed literally to rm and rm will try to delete a file with that name.

The problem is that the character "*" is not legal for filenames in Windows, so when rm tries to delete the file, Windows complains and rm dies.

I meant to add, to illustrate this, try:

rm -f FileThatDoesNotExist.txt

rm won't complain here, because no globs are used.

[Greg Dove]

Just a quick update from me. after the recent changes, the haxe.exe that I build using make now works for me using mingw.

It still has a different size compared to the exe built using install.ml ...but (so far at least) it seems to work fine.

--