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"
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.
On Sun, May 13, 2012 at 8:07 AM, Tony Rogvall <t...@rogvall.se> wrote:
> 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 | Senior Software Engineer
Office: 828.610.4596 | Fax: 828.322.5294 | d...@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-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
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" <
d...@networkintegritysystems.com> написал:
> 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.
> On Sun, May 13, 2012 at 8:07 AM, Tony Rogvall <t...@rogvall.se> wrote:
> > 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 | Senior Software Engineer
> Office: 828.610.4596 | Fax: 828.322.5294 |
> d...@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-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
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.
On Sun, May 13, 2012 at 8:07 AM, Tony Rogvall <t...@rogvall.se> wrote:
> 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"
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
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
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.
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
> 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.
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:
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
> On Sun, May 13, 2012 at 8:07 AM, Tony Rogvall <t...@rogvall.se> wrote:
>> 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"
> -- > Jesse Gumm
> Owner, Sigma Star Systems
> 414.940.4866 || sigma-star.com || @jessegumm
"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"
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.
On Sun, May 13, 2012 at 3:51 PM, Tony Rogvall <t...@rogvall.se> wrote:
> 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.
> 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:
> 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
> On Sun, May 13, 2012 at 8:07 AM, Tony Rogvall <t...@rogvall.se> wrote:
> 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
> --
> Jesse Gumm
> Owner, Sigma Star Systems
> 414.940.4866 || sigma-star.com || @jessegumm
> "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"
-- Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
> 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.
> On Sun, May 13, 2012 at 8:07 AM, Tony Rogvall <t...@rogvall.se> wrote:
>> 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"
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?
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
> 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.
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"
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.
On May 14, 11:04 pm, Tony Rogvall <t...@rogvall.se> wrote:
> > 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.
> 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"
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.
