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
