XCROSS - moving it officially to https://github.com/HaxeFoundation

[Zaxebo Yaxebo]

xcross (written by Nicolas Canasse himself) https://code.google.com/p/xcross/   ,  is still at Googlecode .

may be it xcross's source too  can also Moved to GITHUB https://github.com/HaxeFoundation/  . I mean that, this tool of Nicolas can too be officially taken over by haxe foundation formally.

Zaxebo

[Juraj Kirchheim]

The project isn't published on haxelib and the commit log doesn't
really suggest much activity:
https://code.google.com/p/xcross/source/list

I'm just guessing in the wild, but I think maybe the project has
outlived its usefulness for Nicolas and nobody else in the foundation
finds this particularly useful either (probably because neko is just
not their platform, and even if it is, then only through OpenFL/NME,
which has its own approach to cross compilation).

Moving this library forward would require initiative from someone who
finds it useful. Like yourself. You could move it to GitHub and add
some tests and also publish it on haxelib. That would be a start.

FWIW, if you're not after cross compilation, but merely bundling a
standalone executable, then `nekotools boot <thefile.n>` will actually
do the trick.

Best,
Juraj

> --
> To post to this group haxe...@googlegroups.com
> http://groups.google.com/group/haxelang?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Haxe" group.
> For more options, visit https://groups.google.com/d/optout.

[David Peek]

Unfortunately nekotools boot still requires neko to be installed (well, the dlls/dylibs at least).

[Zaxebo Yaxebo]

1) @back2dos: Thanks for suggestion, I will do it.

   Note: It seems nicolas updated xcross after neko 2.0 , so it means it is somehow alive, even though it is quite 1.5 years since last commit at https://code.google.com/p/xcross/source/list  

----------------------------------------------------------------------------------------------------

2)

Just to add , the executable,sat Test1, generated by "nektools boot" depends (ldd) on libneko.so and libgc.so . 

% ldd Test1

linux-gate.so.1 =>  (0xb77ca000)

libneko.so => /usr/lib/libneko.so (0xb777f000)

libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7764000)

libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75b9000)

libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb75b4000)

libgc.so.1 => /usr/lib/libgc.so.1 (0xb7571000)

libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7545000)

/lib/ld-linux.so.2 (0xb77cb000)

libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7527000)

My main goal was NEITHER to generate a fully static exceutable, NOR to generate a fully dynamic executable like above , BUT I DESIRED TO produce a mixed linked executable which is basically a dynamically linked executable with libneko.so and libgc.so statically linked into it. That is, the desirable executable should show dynamic dependency only on libraries libpthread.so,libc.so etc etc; all the "neko specific libraries" are statically linked into it. This kind of mixed linked executable would have been the "most ideal balanced" combination between - single executable file and portability and executable size  So I will be able to send a single mixed linked executable file with smallest possible size to run it on a system where neko or libgc is not preinstalled(as rest of the dependencies as shown in "ldd" will be preinstalled in all the linux systems of same linux distribution type).

----------------------------------------------------------------------------------------------------

3)

back2dos>> OpenFL/NME, which has its own approach to cross compilation). 

zaxebo>> Can you point me to an url relevant to the mentioned "OpenFL/NME approach"

Zaxebo

[Joshua Granick]

I've run into this same problem, and ideally, a static Neko should be able to both handle statically linked dependencies as well as finding external NDLLs (in the same directory) for things like NME or OpenFL.

I've been doing some though on the cross-desktop compilation question. Neko is one approach, Java would be another, or I've been wondering if node-webkit would be a sensible target for cross-desktop work?

I'd love to hear other people's thoughts on a "best" way for Linux to Mac and Windows (etc) builds :)

--

Using Opera's mail client: http://www.opera.com/mail/

[Ishan Das Sharma]

node-webkit is not a sustainable method, in it's current state at least. We might have better success with atom-shell, but they're both dependant on V8, which can't use more than 1.6? GB of RAM

[PSvils]

I'm not sure I understand correctly - doesn't OpenFL and NME create native/Cpp builds for all platforms? Why would this get moved to a virtual machine?

P.

[Joshua Granick]

Native builds require the operating system to create -- as an alternative (choices!) I'm thinking about a "best" path for cross-desktop builds, that don't require you to boot Linux to build Linux, have Mac OS X to make a Mac build, etc.

[Cauê Waneck]

Josh, a probably easier way would be to add out-of-the-box hxcpp support for cross-compilers.
It's not that much work - at least for command-line apps -, and in the end it will be possible to compile to Windows, Mac, iOs, Android, Linux and whatnot from a Linux box. We already use cross-compilers to be able to compile the Haxe nightly builds - all of them from a Linux box.
I can help you setup the environment for them.