Issue #12124 has been updated by Yui NARUSE.


C.J. Collier wrote:
> I had a meeting yesterday at Microsoft in Redmond with members of the Visual Studio team.  They are excited by the idea of enabling support for autotools in Visual Studio.

That sounds interesting.
If autotools support of Visual Studio, it will ease the maintenance of configure.in/Makefile.in!
(though it needs some Unix tools like grep.exe and sed.exe, and organize current win32/Makefile.sub into new separation) 

> We spoke about the possibility of releasing the nmake source code under a license such as X11/MIT.  I am hopeful about the possibility, but of course Microsoft is a large company and they will need to acquire clearance from the developers who wrote the code, management of the Visual Studio team, and LCA before being able to make such a thing possible.
> 
> If this were to happen, I expect that it would be relatively easy to convince the automake team to add native support for another Free Software make platform.

It's great!
We sometimes hit nmake compatibility issue like folloing.
I wish it would help to avoid such issue.

```
e56b9b4 common.mk: dependency of ripper.c
655b18e common.mk: source dependency for nmake
184c7e6 common.mk: probes.dmyh for nmake
f6dcbf7 nmake VPATH
52ddf1f Revert r53482 "nmake VPATH"
64e2285 nmake VPATH
445e11d probes.h including dummy header
a1115a1 * ext/ripper/depend: Just like BSDmake, nmake also recognize the rule of   ".eventids2.check" as inference one.  but nmake is not cheated by macro.   this fixes build failure introduced at r53448. see also the commit log of   r53452.
fabb8b4 enc/Makefile.in: get rid of nmake bug
bae170f common.mk: double quotes
```

----------------------------------------
Misc #12124: Use Automake
https://bugs.ruby-lang.org/issues/12124#change-58151

* Author: C.J. Collier
* Status: Open
* Priority: Normal
* Assignee: C.J. Collier
----------------------------------------
It looks like there is a lot of duplicate code that could be removed by making use of automake.

Are there any reasons why this should not be done?

I've got some patches up for review here:

https://github.com/ruby/ruby/compare/trunk...LLC-Technologies-Collier:trunk?expand=1



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>