[erlang-questions] windows

[Tony Rogvall]

Dear erlang-ers.

Is there anyone on this list that do develop on windows ?

How on earth do you do that ? ;)

I am trying to get a driver compiled using rebar.

rebar is nearly working on MingW but git is not available for MingW, the reason is somewhat bizarre ...

rebar is nearly working on cygwin but there is some path problem that result in "access denied".

Right now I reverted to using a Makefile with MingW, that after lots of copy and past finally works.

Is rebar supposed to be working with cygwin/mingw ?

BTW 

I will NOT install Visual Studio XYZ :-)

Thanks

/Tony

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"

[Daniel Goertzen]

I am also unable to make rebar work on Windows. Whenever I download
something with a rebar script, I have to basically open it in an
editor "execute" it by hand and hack everything into place... even for
straight forward things with no C compiling like gproc. No fun at
all.

I settled for cygwin Make, and I was able to build a working NIF
module using the compile command indicated in the NIF tutorial. The
Makefile is completely Windows specific, but it meets my needs. This
of course uses Visual Studio... which is a free download and really
not a big deal to install.

Dan.

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>



--
Daniel Goertzen | Senior Software Engineer
Office: 828.610.4596 | Fax: 828.322.5294 | da...@networkintegritysystems.com
Network Integrity Systems | We Bring Security To Light™

1937 Tate Blvd. SE

Hickory, North Carolina, USA 28602

Network Integrity Systems’ INTERCEPTOR™ Optical Network Security
System is a Smart-PDS™ that ensures superior protection and cost
effectiveness of classified networks.  For more information, visit our
website at:www.networkintegritysystems.com.


__________________________________________
INTERCEPTOR™ Optical Network Security System is made in the USA for
the USA. Although not an export controlled item, because of the role
it plays in the assurance of the safety and integrity of National
Security Information, Network Integrity Systems (NIS) is committed to
compliance with the U.S. Export Administration Act. Accordingly, NIS
will not ship INTERCEPTOR products to certain foreign government end
users without U.S. government approval and will refuse transactions
with individuals or entities that have been denied export privileges.
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Dmitry Melnikov]

Hi, I am using vs + cmake + rebar. C++ part is buit with cmake + vs and rest erlang code is buit with rebar. All build procedures is made from one build.bat file. Works well.

13.05.2012 18:16 пользователь "Daniel Goertzen" <da...@networkintegritysystems.com> написал:

[Jesse Gumm]

Hi Tony,

I spent a lot of time fighting with Windows (Mingw/Msys), Rebar, and
Erlang to get them all playing nicely together well to generate a
decent windows release for Nitrogen, and it works pretty reliably now.

You can use my instructions for compiling Nitrogen as a basis for
getting your stuff working:
https://github.com/nitrogen/nitrogen/blob/master/rel/overlay/win/README.md

-Jesse

On Sun, May 13, 2012 at 8:07 AM, Tony Rogvall <to...@rogvall.se> wrote:

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>



--

Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[Tuncer Ayaz]

On Sun, May 13, 2012 at 3:07 PM, Tony Rogvall wrote:
> Dear erlang-ers.
>
> Is there anyone on this list that do develop on windows ?

All Windows support in rebar is from contributors using rebar on
Windows. I remember it's being used for building drivers plus reltool
and appup support.

> rebar is nearly working on cygwin but there is some path problem
> that result in "access denied".

Can you file a ticket or mail the rebar list with more info?

> Is rebar supposed to be working with cygwin/mingw ?

From what I recall it's being used in cygwin, mingw, and plain Windows
with various shells.

> BTW
> I will NOT install Visual Studio XYZ :-)

There is nothing depending on msvc in rebar's native code plugin. All
of it is configurable via rebar.config and environment variables.

Please see
1. {port_env, []} in rebar.config.sample
2. default_env/0 in rebar_port_compiler.erl

[Tuncer Ayaz]

On Sun, May 13, 2012 at 4:16 PM, Daniel Goertzen wrote:
> I am also unable to make rebar work on Windows. Whenever I download
> something with a rebar script, I have to basically open it in an
> editor "execute" it by hand and hack everything into place... even
> for straight forward things with no C compiling like gproc. No fun
> at all.

Is that because Makefiles have rules to run "./rebar CMD"? It's
preferable to run it as "rebar" and therefore if required use the
rebar.cmd wrapper.

[Tony Rogvall]

On 13 maj 2012, at 20:56, Jesse Gumm wrote:

Hi Tony,

I spent a lot of time fighting with Windows (Mingw/Msys), Rebar, and
Erlang to get them all playing nicely together well to generate a
decent windows release for Nitrogen, and it works pretty reliably now.

You can use my instructions for compiling Nitrogen as a basis for
getting your stuff working:
https://github.com/nitrogen/nitrogen/blob/master/rel/overlay/win/README.md

Thanks

Installing the (very full installer) msysgit worked

 (have not tried all fancy features of rebar yet)

I also stumbled on that I had written a special spec:

     {"(win32)","priv/dthread_drv.dll",

      ["c_src/dthread.c", "c_src/dthread_drv.c"]},

The string "priv/dthread_drv.dll" had the effect that the driver was named ".dll" so 

I had some problem finding it :-) using "priv/dthread_drv.so" fixed it (strange ?) 

Now it loads and runs under both mingw (msysgit) and werl

/Tony

[Jesse Gumm]

Excellent! Glad that helped!

It can become quite cumbersome fighting with MinGW and the multiple
version of `make` (mingw32-make.exe, a downloaded version of
`make.exe` from the msys repo, etc). It's not clear at all,
especially with the names 'netinstaller' and 'fullinstaller', where
the 'netinstaller' is the "more full installer" like you mentioned.
Also, apparently, if you copy msys's copy of make into a normal mingw
installer, it just hangs because there's some DLL dependency. The
documentation is scattered, sparse, and online discussions about msys
and mingw all seem to be referring to old versions that no longer work
as you'd expect.

That first time I got all my stuff to compile with msysgit and rebar
and generating the erlang release - that was a good day. And Tuncer
has been great about accepting patches for Windows rebar and providing
insights into rebar workings.

-Jesse

[Dmitry Kolesnikov]

Hi,

Like Jesse, "I spent a lot of time fighting with Windows..." but then switched to Linux.
Everything works out of box, I am not fighting anymore ;-)

Just get VirtualBox + Fedora LXDE... BTW, If you are planning to host your results on Linux then probably you should have it at R&D env.

- Dmitry

[Tuncer Ayaz]

On Sun, May 13, 2012 at 10:44 PM, Tony Rogvall wrote:
> The next thing was that I specified:

>
> {"(win32)","priv/dthread_drv.dll",
> ["c_src/dthread.c", "c_src/dthread_drv.c"]},

You don't need that win32 rule.
rebar automatically switches the extension on Windows as follows:
1. priv/foo_drv.so -> priv/foo_drv.dll
2. priv/foo -> priv/foo.exe

> This leads to the (bug?) that the spec ended up as {spec, drv,
> ".dll", ...} the file was linked as .dll, no wonder I could not find
> it :-)

Thanks for the bug report. Can you confirm it's fixed in the ta-dll
branch?

[Tony Rogvall]

On 14 maj 2012, at 22:30, Tuncer Ayaz wrote:

On Sun, May 13, 2012 at 10:44 PM, Tony Rogvall wrote:

The next thing was that I specified:

    {"(win32)","priv/dthread_drv.dll",

     ["c_src/dthread.c", "c_src/dthread_drv.c"]},

You don't need that win32 rule.
rebar automatically switches the extension on Windows as follows:
1. priv/foo_drv.so -> priv/foo_drv.dll
2. priv/foo -> priv/foo.exe

Yes I noticed ;-)

This leads to the (bug?) that the spec ended up as {spec, drv,

".dll", ...} the file was linked as .dll, no wonder I could not find

it :-)

Thanks for the bug report. Can you confirm it's fixed in the ta-dll
branch?

Next time I start windows. Unfortunately this week.

[eigenfunction]

I develop on windows+cygwin and Linux in about 50/50. That's one
reason why rebar was a no go for me. On the other hand, sinan works
perfectly in both environment for me. Most of the times, i use the
same code base shared between windows and linux with the same sinan
and i just switch in and out of the virtual machine to test in both
environments.
Just my 2 cents.

> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.orghttp://erlang.org/mailman/listinfo/erlang-questions

[Tuncer Ayaz]

On Mon, May 14, 2012 at 11:04 PM, Tony Rogvall wrote:
>
> On 14 maj 2012, at 22:30, Tuncer Ayaz wrote:
>
> On Sun, May 13, 2012 at 10:44 PM, Tony Rogvall wrote:
>
> The next thing was that I specified:
>
>
>     {"(win32)","priv/dthread_drv.dll",
>
>      ["c_src/dthread.c", "c_src/dthread_drv.c"]},
>
>
> You don't need that win32 rule.
> rebar automatically switches the extension on Windows as follows:
> 1. priv/foo_drv.so -> priv/foo_drv.dll
> 2. priv/foo -> priv/foo.exe
>
> Yes I noticed ;-)
>
> This leads to the (bug?) that the spec ended up as {spec, drv,
>
> ".dll", ...} the file was linked as .dll, no wonder I could not find
>
> it :-)
>
>
> Thanks for the bug report. Can you confirm it's fixed in the ta-dll
> branch?
>
>
> Next time I start windows. Unfortunately this week.

Merged the fix to master.