Re: call for help/crazy idea: nmake support

[Steffen Dettmer]

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 <address@hidden> 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