Re: call for help/crazy idea: nmake support
Hi! This is an interesting discussion. I think a key question is whether the style of working with Integrated Development Environments (IDEs) is compatible with `orthogonal component based environments'. I tend to think that both are, more or less, each others opposite. In first case, I have a one-fits-all tool (like Eclipse). Everything included is specific (Eclipse-editor, eclipse-etags, eclips-debugger etc), which is needed to integrate the things. Advantages include that the debugger knows tags and you can set breakpoints in the editor window etc. but it might be hard to replace a part of it (let's assume someone wants to use a different editor - impossible without losing the great features). In second case, several small tools (the simpler, the better) are used together and each can be exchanged separately. Use any editor, any compiler and any debugger. You can use source code generated e.g. by self-written parser generators and implement parts in own languages, if desired. If I understood correctly, nmake support and MSVC *.DSP project file support aim to build a brigde between both cases. I have difficulties to imagine how it could look like, especially when considering the non-trivial cases. On Sat, Jul 31, 2010 at 7:26 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Here's a crazy idea: how about if automake optionally output an input file suitable for nmake (after configure substitution)? What would be the intended main usage? Building C/C++ with CL.EXE only? What would be the motivation? I assume it is for systems that cannot run configure, have no make and have no special requirements (only C/C++, no BUILT_SOURCES etc). Is that even feasible? (I'd guess so) Maybe if we have contents conditional on 'make' or 'nmake' output? Alternatively, some special make rules could create nmake makefile and include it in the source dist. Depending on the simplifications / limitations acceptable for the nmake makefile, maybe it could be constructed from a static template (to be adjusted on major changes) but just honor the _SOURCES variables dynamically. We use a set of GNU Make rules to get the _SOURCES into a file used to form MSVC6 DSP files; I think creating a nmake file shouldn't be more difficult. Would that even help anybody? (no idea) MS Visual Studio users probably would gain no benefit; if they use make or nmake AFAIK does not matter much. Having .DSP files can add benefits. The debugger also works without .DSP files, but the IDE won't (of course it needs to know the sources to index symbols etc). Is there anybody willing to work on this? Should I prepare a Summer of Code/other code sprint project proposal[1]? Or is a better alternative to follow the path we have taken with Libtool (finally getting MSVC support in) also in Automake, with Peter's patches and more? I know developers that love to use the MS Visual IDE and are quick with it. They are glad even for somewhat limited DSP file support (in our case, BUILT_SOURCES won't work and require some special manual action, but compiling etc works). Personally, I dislike this (which is easy for me, because I do not use Visual Studio - otherwise, probably I would see things differently :)). If BUILT_SOURCES do not work comforable, people then avoid using it. In the end #defines aren't in config.h but in mymodcfg.h etc. I don't know Peter's patches, but I'm afraid that the working style of autotools and IDEs differ and thus DSP file generation could even be contra-productive (e.g. when resulting in the habbit not to use BUILT_SOURCES, beause some platforms do not support it, but of course it is no objective of autotools to enforce some good style developments or so). For people only using a (source dist) package, it shouldn't matter a lot whether to use DSP files or Makefiles, should it? oki, Steffen
Re: RE : call for help/crazy idea: nmake support
On Fri, 2010-08-13 at 19:18 +0200, Ralf Wildenhues wrote: [snip] And of course I would be delighted if some of you provided fixes for pkg-config and whetever else is needed to make building for this setup work better. The problem with pkg-config is that it relies a lot on POSIXy development environment conventions. And outside of systems that provide such a development environment on Windows, there's no conventional place to put pkg-config's *.pc files. And if there were, you'd need to get various SDK installers to start using it. Oh, and my own experience is that I wind up using library dependencies that don't even have installers per se; so in these cases a *.pc file would need to be manually constructed. I'm quite happy just adding -I and -L flags to CPPFLAGS and LDFLAGS as necessary. -- Braden McDaniel bra...@endoframe.com
Re: RE : call for help/crazy idea: nmake support
I would like to thank everyone who provided input on this topic. It certainly helps when considering where to go. One conclusion from this is that we should get Peter's MSVC support finished and completed for Automake 1.12 and the next Libtool release. I wasn't aware that there are more MSVC-related build system tools which one could target. I'm still not sure whether the idea to produce support for some of them should be buried completely, but I for one won't be pursuing it in the nearer future. If somebody else feels scratching that it however ... And of course I would be delighted if some of you provided fixes for pkg-config and whetever else is needed to make building for this setup work better. Thanks, Ralf
Re: call for help/crazy idea: nmake support
On Sat, 2010-07-31 at 19:26 +0200, Ralf Wildenhues wrote: Here's a crazy idea: how about if automake optionally output an input file suitable for nmake (after configure substitution)? Is that even feasible? (I'd guess so) Maybe if we have contents conditional on 'make' or 'nmake' output? Would that even help anybody? (no idea) Is there anybody willing to work on this? Should I prepare a Summer of Code/other code sprint project proposal[1]? nmake really does live in a different universe. Just for example, CPPFLAGS are for the C++ compiler in nmake, not the preprocessor. And is nmake really used for anything nontrivial these days? I suppose the main thing that Automake would bring to this party is automatic dependency generation. And assuming one cares about nmake in the first place, I guess that's pretty nice. Or is a better alternative to follow the path we have taken with Libtool (finally getting MSVC support in) also in Automake, with Peter's patches and more? I'm certainly quite eager to see this in Automake and Libtool. I suspect this will hit the sweet spot for a lot of autotools users. -- Braden McDaniel bra...@endoframe.com
Re: call for help/crazy idea: nmake support
On Tue, 2010-08-10 at 16:38 -0700, Natalie Tasman wrote: Hi Ralf, I think this is a great idea and would be interested in hearing your plans for moving forward. I've invested a lot of time in an autotools build system that works on *nix and mingw (and cross-compiling to mingw from linux!) and I do think this would be interesting to see this work on mingw shell with MSVC's build system, as you propose. Although, to be honest, I have recently been taking another look at other build systems such as cmake, which does generate full MSVC-native project files, which is very attractive. I'm sure this is heresay, but I'll at least voice my interest in a dream solution: autotools with Visual Studio project file generation. Part of the problem with Visual Studio project file generation is the frequency with which the file format changes--sometimes a little, sometimes a lot. But every couple of years or so, something's likely to change. msbuild (of which I understand modern project file formats to be a subset) might be a better target. The long term stability of the file format doesn't have much of a track record yet; but one can choose to be optimistic. It does deliver a command line build without a Bourne shell, which I'm guessing is the major attraction of nmake. But unlike nmake, it has quite a few modern features. A related, possibly basic question: if mingw's gcc builds msvc-compatible DLLs, etc, what do people see as the benefit to using a mingw/sh-driven MSVC build? Good enough for C; but if you wants to build a DLL with C++ interface features, you generally still need to use the same compiler as other code you're playing with. -- Braden McDaniel bra...@endoframe.com
Re: RE : call for help/crazy idea: nmake support
On Wed, 2010-08-11 at 08:34 +0200, PICCA Frédéric-Emmanuel wrote: Hello I'm certainly quite eager to see this in Automake and Libtool. I suspect this will hit the sweet spot for a lot of autotools users. the problem I see is that a lot's of peoples relies on pkg-config during the configuration phase. How can we deal with this on windows platform ? I think the answer is that you can either augment or replace use of pkg-config. I suspect anyone expecting these changes to libtool to make autotools packages Just Work on Windows will be disappointed. And I would be shocked if pkg-config is the only reason for that. -- Braden McDaniel bra...@endoframe.com
Re: call for help/crazy idea: nmake support
Hi Ralf, I think this is a great idea and would be interested in hearing your plans for moving forward. I've invested a lot of time in an autotools build system that works on *nix and mingw (and cross-compiling to mingw from linux!) and I do think this would be interesting to see this work on mingw shell with MSVC's build system, as you propose. Although, to be honest, I have recently been taking another look at other build systems such as cmake, which does generate full MSVC-native project files, which is very attractive. I'm sure this is heresay, but I'll at least voice my interest in a dream solution: autotools with Visual Studio project file generation. A related, possibly basic question: if mingw's gcc builds msvc-compatible DLLs, etc, what do people see as the benefit to using a mingw/sh-driven MSVC build? -Natalie On Sun, Aug 1, 2010 at 11:11 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Philip Herron wrote on Sun, Aug 01, 2010 at 08:05:50PM CEST: This sounds amazing on one of my other projects i support a cmake build along side my autoconf and automake for everything that isn't windows lol. So let me rephrase the question: if we have the ability to build completely with MSVC within a shell environment such as MinGW/MSYS would people still need something like nmake support? With git versions of Automake and Libtool, we are actually quite close to the former. Thanks, Ralf
Re: call for help/crazy idea: nmake support
(This bounced the first time I sent it, sorry if it reposts) On Sat, Jul 31, 2010 at 01:41:29PM -0700, David Byron wrote: On Saturday, July 31, 2010, Ralf Wildenhues wrote: Here's a crazy idea: how about if automake optionally output an input file suitable for nmake (after configure substitution)? Is that even feasible? (I'd guess so) Maybe if we have contents conditional on 'make' or 'nmake' output? Would that even help anybody? (no idea) I don't think this would help that many people. If someone is running autotools (or even a generated configure script) on windows, I think we can assume they've either got cygwin or msys which implies access to make. If they've got make I can't see why they'd need to use nmake. Yes, I agree. A few reasons off the top of my head, There is a large audience of automake build systems that have taken advantage of custom rules for specific make implementations (ie. gnu make). These real-world build systems wouldn't port to nmake without a lot of rework. Also, it's been reported that using sh is much faster than using cmd directly. http://labs.trolltech.com/blogs/2007/01/30/qtmsys/ It also turns out compilation using sh is way faster than using cmd.exe. I'm guessing nmake uses cmd (that's strictly a guess), and would probably be unnecessarily slow. It's easy to get make/sh support via cygwin or msys these days, so there is no real reason not to have it on windows (which is the main target area for MSVC support). Also, you probably already need this sort of support if you want to run configure. Or is a better alternative to follow the path we have taken with Libtool (finally getting MSVC support in) also in Automake, with Peter's patches and more? I like this approach much better. All the hand-maintained versions of cccl would finally disappear. Yes, this approach would benefit a lot of people, a lot faster. I second this opinion. Bob
Re: call for help/crazy idea: nmake support
* David Byron wrote on Sat, Jul 31, 2010 at 10:41:29PM CEST: If someone is running autotools (or even a generated configure script) on windows, I think we can assume they've either got cygwin or msys which implies access to make. OK, so what if they are not actually running configure (or would not actually need to)? Presumably automake could produce a ready nmake file (or forbid, a vcproj) in at least simple cases? Or is a better alternative to follow the path we have taken with Libtool (finally getting MSVC support in) also in Automake, with Peter's patches and more? I like this approach much better. All the hand-maintained versions of cccl would finally disappear. I'm not trying to shoot down this approach at all, BTW. On the contrary. Cheers, Ralf
RE: call for help/crazy idea: nmake support
On Saturday, July 31, 2010, Ralf Wildenhues wrote: * David Byron wrote on Sat, Jul 31, 2010 at 10:41:29PM CEST: If someone is running autotools (or even a generated configure script) on windows, I think we can assume they've either got cygwin or msys which implies access to make. OK, so what if they are not actually running configure (or would not actually need to)? Presumably automake could produce a ready nmake file (or forbid, a vcproj) in at least simple cases? I could use some more info on how this would work in practice. Does this mean that tarballs of packaged source contain an nmake file in addition to configure and Makefile.in? I don't think it's safe to assume that one nmake file is sufficient for all MSVC tool + Platform SDK versions. Plus also, if end users don't run configure they lose the ability to pass args to configure (either --with-* or environment variable definitions). -DB
Re: call for help/crazy idea: nmake support
* David Byron wrote on Sun, Aug 01, 2010 at 07:25:16PM CEST: On Saturday, July 31, 2010, Ralf Wildenhues wrote: OK, so what if they are not actually running configure (or would not actually need to)? Presumably automake could produce a ready nmake file (or forbid, a vcproj) in at least simple cases? I could use some more info on how this would work in practice. Does this mean that tarballs of packaged source contain an nmake file in addition to configure and Makefile.in? I don't think it's safe to assume that one nmake file is sufficient for all MSVC tool + Platform SDK versions. Plus also, if end users don't run configure they lose the ability to pass args to configure (either --with-* or environment variable definitions). Sure. I have no idea yet how exactly this could work in practice. I don't know these tools yet. I'm just throwing out these ideas to see if somebody has good input. In such a project, is there any scripting besides CMD that one could rely on? Thanks! Ralf
RE: call for help/crazy idea: nmake support
On Sunday, August 1, Ralf Wildenhues wrote: Sure. I have no idea yet how exactly this could work in practice. I don't know these tools yet. I'm just throwing out these ideas to see if somebody has good input. In such a project, is there any scripting besides CMD that one could rely on? I suppose autoconf could generate a configure-like script tht works with CMD files or Windows Scripting Host (http://en.wikipedia.org/wiki/Windows_Script_Host) to generate nmake files. Seems like a lot of work though. It also seems like it depends on support for the native MS tools using the existing configure script mechanism. -DB
Re: call for help/crazy idea: nmake support
On 31 July 2010 18:26, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Maybe if we have contents conditional on 'make' or 'nmake' output? Would that even help anybody? (no idea) Is there anybody willing to work on this? This sounds amazing on one of my other projects i support a cmake build along side my autoconf and automake for everything that isn't windows lol. I really dislike using cmake it really is a hardcoded build system in my eyes lol. But i think all anyone needs is automake to output nmake, the only thing i am not sure how it would work is would we need some kind of already hardcoded nmake for finding the compiler etc or something or it may require autoconf work to to fill in the gaps? In practice with cmake does this by running cmake CMakeLists.txt in your cmd prompt and this iterates over to find all the tools it needs and generates the nmake file which you can open in visual studio and run compile on or you can even run nmake in the cmd prompt too. Problem i foresee is some kind with autoconf i am not sure if it runs well on windows to find what you need my initial thoughts say yeah with cygwin etc. But thats not very windows'y. But i would say most build environments are very static on windows in that you could nearly hard-code compiler and lib paths within the nmake but thats not in the spirit of autoconf. What you could have is an automake switch to generate an nmake.in and then the work could be passed to some kind autoconf .bat ouput would be the best to generate the final nmake or somthing but it sounds like a lot of work. But thats just my thoughts as an outsider :) --Phil
Re: call for help/crazy idea: nmake support
On 8/1/2010 2:11 PM, Ralf Wildenhues wrote: So let me rephrase the question: if we have the ability to build completely with MSVC within a shell environment such as MinGW/MSYS would people still need something like nmake support? Speaking for myself and my projects -- no, I would not.
RE: call for help/crazy idea: nmake support
On Saturday, July 31, 2010, Ralf Wildenhues wrote: Here's a crazy idea: how about if automake optionally output an input file suitable for nmake (after configure substitution)? Is that even feasible? (I'd guess so) Maybe if we have contents conditional on 'make' or 'nmake' output? Would that even help anybody? (no idea) I don't think this would help that many people. If someone is running autotools (or even a generated configure script) on windows, I think we can assume they've either got cygwin or msys which implies access to make. If they've got make I can't see why they'd need to use nmake. Or is a better alternative to follow the path we have taken with Libtool (finally getting MSVC support in) also in Automake, with Peter's patches and more? I like this approach much better. All the hand-maintained versions of cccl would finally disappear. -DB
