Board index » Visual Studio » Command line compiler

Visual Studio356
Hi all,



I'm a GNU/Linux developer trying to get comfortable with developing on the

Microsoft platform. At work I have Visual Studio 2003 version 7.1.3088.



I would like to use a command line compiler, my own Makefile, and my own

editor to develop software. I would like to forego the IDE completely.



I've read that there's a command line VC++ compiler called cl.exe, and even

found it sitting on my hard drive:



C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe



However, when I try to run the command line compiler (just typed "cl.exe"), I

get a pop-up window with the error message:



This application has failed to start because mspdb71.dll was not

found. Re-installing the application may fix this problem.



I did a quick search and can't find that dll.



Can someone post simple instructions on how I can get up and running with the

command line version of a visual C++ compiler?



Thanks,

Pete


-

Peter Jay Salzman wrote:

Try running the vcvars32.bat in the same directory in your script or

batch file. CL should then run fine.



Josh McFarlane



-

I realize you are free to use whatever approach you like.



However, as someone who is comfortable with compiling in the IDE, I can't

imagine why you'd want to eliminate that in favor of a command line compiler

and makefile.



I recall the days where I created a makefile and ran nmake. All I can say is

"thank god those days are over."



--

Jonathan Wood

SoftCircuits Programming

www.softcircuits.com">www.softcircuits.com



"Peter Jay Salzman" <p@dirac.org>wrote in message



-

This will all work from command line as well. You will however need to

set the environment. vcvars32.bat or something on lines to set the

variables and then run cl.exe.



---

Ajay



Peter Jay Salzman wrote:

-

Wow! You really enjoy misery! (I'm an old Unix programmer, and nothing has made me

happier than never again having to look at a makefile. And I used to be the Wizard of

Makefiles--people would come to me to get their makefile problems fixed...)



You can always just call cl.exe; that's all the IDE does anyway. Back pre-VS, I used to

write makefiles and call cl from the makefile rules.



Note that you must have the appropirate directory in your search path to make this work;

otherwise, the necessary DLLs may not be findable. When you install VS, it usually gives

you an option of creating a little .bat file that contains all the necessary SET options,

which in the pre-vs days, I would invoke as part of my "build" sequence.



You will also need to make sure your INCLUDE= and LIB= paths are set. It has been about

15 years since I've had to look at makefiles, so I'm not up on all the details any longer.

I used to write programs that generated makefiles (one called "makemake", which my client,

who lived in Hawaii, would pronounce "mocky-mocky")



The mspdb71.dll should definitely be installed, and I found it in my installation. It is

not, however, in the bin directory. I set the compilation up by setting the following

directories to the PATH variable:



c:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;c:\program files\Microsoft

Visual Studio .NET 2003\Vc7\bin



Note the Common7 directory must be added. When I ran the cl command from the command

line, it worked fine, except that I didn't have all the options set right in the command

line so I got a lot of errors about missing command line options, but it actually tried to

compile my .cpp file.

joe





On 1 Jun 2006 17:36:31 +0200, Peter Jay Salzman <p@dirac.org>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

Some people just don't believe in modern technology. I was apalled, when I returned to

the University environment in 1990, that when I left in 1980, the state-of-the-art in

software development was the "cc" command and "cdb" as a debugger (one of the more

horrible debuggers to have ever been written). When I returned in 1990, the

state-of-the-art was the "gcc" command and "gdb" as a debugger (gdb copied all the flaws

of cdb; the solution of the free software community is to continue to propagate Really Bad

Ideas into perpetuity). And, as far as I can tell, there has been no progress in the

intervening 16 years in the Unix world. (In 1990, I was already doing better than this; in

fact, I ended up doing all my development on my 33MHz PC, which compiled faster than the

$60,000 IBM workstation in my office; besides, on my PC, the compiler worked, the linker

worked, and the debugger worked, all of which were rather important to me, and none of

which worked on the IBM workstation; the debugger on my PC [codeview] was of vastly better

quality as far as the user interaction than gdb, even if gdb had worked right).



There seems to be an aura of "real programmer" in the use of these rather primitive tools.

Frankly, I much prefer living in 2006 with 2006 tools than in 2006 with 1980 tools

(actually, the tools were probably about 1978). Of course, VS.NET kind of interferes with

my attitude, but that's because it is a giant step backward in IDEs.

joe



On Thu, 1 Jun 2006 15:21:31 -0600, "Jonathan Wood" <jwood@softcircuits.com>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

Thanks, guys. It works! :-)



Is there a file that gets executed each time I open a new shell? Ideally,

I'd like to stick this in there:



PROMPT=$$

C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat



so that these two commands run each time I open a new command prompt. I seem

to recall autoexec.bat from way back in the day, but I *think* that file gets

executed once at boot time, so it's not appropriate for running something

each time I open a new command prompt.



Thanks SO much!

Pete



Ajay Kalra <ajaykalra@yahoo.com>wrote:

Well, it has nothing to do with being a "real programmer". I'm about the

least macho programmer there is. I use whatever technology I'm fast,

competant and feel comfortable with. I see the benefits of both Linux and

Microsoft, and thoroughly enjoy both technologies.



But you (I hope you don't take offense) give off the aura of a zealot, and

absolute dogma is never a good thing.



When you see so many people using a technology, there's usually at least some

good in it. By cutting yourself off from something, as it _sounds_ you've

done with Unix tools, you make sure of a zero possibility of taking the best

from the technology and incorporating it into your own tools.



For my own part, I just really, really love vim. I seem to be faster with

vim than anyone else is with any other high level editor. I also find that I

like the flexibility of make (and ant, by the way).



I understand that it's possible to embed vim in VS. Someday I'd like to look

into how to do that. But for now, the simple and fast solution is to do

everything either in cmd.exe or with cygwin.



Anyhow, I advocate a moderate position with respect to all technology. I use

whatever I'm fast and comfortable with. I happen to love vim, Makefiles, and

command line tools.



You say that VS.net was a step backward. Perhaps other people think that

VS2003 was a step backward. I say: let everyone have their own opinions.

That's what makes the world so interesting. Imagine if everything were

homogeneous. What a bore that would be!



Pete





Joseph M. Newcomer <newcomer@flounder.com>wrote:

All I would say is: Try getting to the point where you are used to compiling

from the IDE and then see how the two methods compare. I won't say you

should do it one way or the other, but the vast majority of people using

this tool find the IDE far more easy and productive. And I think there are

valid reasons for this.



Just a thought.



--

Jonathan Wood

SoftCircuits Programming

www.softcircuits.com">www.softcircuits.com



"Peter" <p@nospam.dirac.org>wrote in message



-

Jonathan Wood <jwood@softcircuits.com>wrote:

No, I agree with you. Actually, I usually do use the VC++ IDE.



I'm basically a C/C++ programmer who was hired by a company that seems to

love Java (I was hired for my math knowledge, not my programming knowledge).

Part of my current project requires interfacing C and C++ with Java, so I've

been learning the JNI API



I've been working through a book on JNI, which requires that I create library

files. I've been following along with the examples and doing exercises both

on Windows and Linux.



Since for this particular purpose I need to write, edit, compile, and run

Java programs, the easiest thing to do (for me) is to use vim with

makefiles. So my Makefile entries would look something like:



0. Write the Java program.

1. Use javac to compile a .java to a .class file.

2. Use javah to generate a .h file from the .java file.

3. Implement the functions prototyped in the .h in a .cpp file.

4. Compile the .cpp file into a .dll (or .so) file.

5. Use java to run the .class file which loads the .dll (or .so) file.



I wouldn't know how to do all this with Visual Studio. However, with Make,

it's the simplest thing on the entire planet.



Since I created a template Makefile to do all this, whenever I work on a new

program, all I need to do is change the first line from:



TARGET = HelloWorld



to:



TARGET = IntArrayTest



and I'm done. It, quite literally, takes me 3 seconds. Two if I hurry. :)

I wouldn't know how to do this with Visual Studio.



But other than this, I often do use the the VS IDE.



I also use the command line stuff for little test or proof of concept

programs, like testing out the behavior of a particular function. I can

usually have the program written and compiled using command line tools by the

time I tell VS where to put a new project. Well... not quite. But

honestly, this isn't too much of a hyperbole. :)



But for larger projects on Microsoft Windows, I often do use the IDE.



Pete

-

Those are the "prebuild", "postbuild" steps, not at all hard to add to VS. I've done it

frequently. I had a yacc parser that was a prebuild step and a version number incrementer

that is a postbuild step. In the case of building a DLL, you set the application to run

the DLL under as "java" with the appropriate command line.

joe



On 2 Jun 2006 23:04:08 +0200, Peter <p@nospam.dirac.org>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

It isn't dogma; I'm vastly more productive with the Microsoft tools than with the

Unix/Linux tools. I started with punched cards, and have been through a *lot* of

technologies in something over four decades. NOTHING would induce me to go backward to

the primitive tools of Unix/Linux. I've watched people use these as recently as three

years ago, and was apalled that they think this stuff is state-of-the-art. They even

reject really great tools like Eclipse, because they "take too much out of my control",

which is kind of scary.



My view of "so many people using it" is that, in my experience, they've never seen

anything better. Any time I see people using these tools, I see that they spend a *lot*

of time working with paradigms that I abandoned 15 years ago. There are even some of them

that think 'vi' is an editor. (As we all know, EMACS is the Only Real Editor. Microsoft

is only one step aboive 'vi', and they haven't yet figured out that editors are not

technology, they are religion).



I'm very serious about the usability of the Unix tools; when I had to go back and use

them, and I'd been an expert in them, I was amazed to find out what a colossal step

backward I had to take to use them. It was like going back to submitting card decks and

waiting hours to get the output. Amazingly enough, you can't actually edit running code

and have it replaced on-the-fly! The compiler, at least as of five years ago, according

to the folks I was working with at the time, gave no real debug support, such as

initializing local variables or having a debug heap runtime that helped find bugs in

storage allocation. Capabilities I take for granted today in Microsoft products appear to

be unavailable in the GNU tools. Debugging a port on a Unix box in 1997 was a truly

amazing experience in what I now look upon as the Dark Ages of software development

technology. I turned to my (Unix) co-developer and asked, in astonishment, "How can you

LIVE with such primitive tools?"



Tolerating bad technology doesn't prove the technology is good; if all you have to do a

job is a 1978-level tool, and you have to do the job, you use the 1978-style tool.

Remember, Unix is just a classic example of a 1965 operating system--all the key

principles of Unix were known in 1965. Unix didn't even invent "pipes", it just

popularized them by giving a nice syntax,



make, the last time I used it, wasn't flexible at all. In 2000, I could still not specify

that this file, and this file only, is compiled with this compiler option, and this other

file is compiled without the standard compiler option. In VS, I just click a few options

and all this falls out.



And there are no precompiled headers, which is one of the reasons I could do a rebuild in

30 seconds on a (by comparison to modern machines) slow laptop while my Unix colleague

took three minutes on a high-end workstation for the same build, using the same sources

(except for the dozen or so modules that were the platform-specific modules).



At this point in my life, I have abandoned pretty much all the Unix tools, except awk.

Mostly because I have vastly superior replacements.



Note that I don't edit in VS. The VS editor sucks. I edit using an external editor, and

it causes me no particular problem. I edit commas and semicolons in the VS editor, but do

the real work in an editor I find highly effective, so there's no reason to abandon all

the VS capabilities because you don't like the editor. As far as I can tell, only the guy

at Microsoft who wrote the editor thinks it is an "editor" as opposed to, say, "a piece of

crap". Internallly, a huge number of Microsoft programmers don't use the VS editor for

the same reason I don't.



All you need in your external editor is the ability to have it detect changes in the files

when you switch back to it. VS has one checkbox that lets it automatically reload any

file you've changed, so that is no problem. But you get a really effective build system,

an excellent interactive debugger, and even a tolerable source browser (although I don't

use it, I use EMACS "tags" mode, which is much faster). And you get the compile-and-go

feature--edit the source code "live", while it's running, and keep debugging without

having to stop the program and restart it to get back to your current debugging state (in

fact, many of my apps in the debug build have a "breakpoint" button that simply takes a

breakpoint, after which any changes will be recompiled. This lets me edit and test in

"real time" without having to "resubmit my card deck". That's worth a lot. I haven't

used a command line to compile since the first version of VS came out. And I haven't

missed it. I certainly have never missed a 'makefile'. Most of my expertise in makefiles

was in working around their considerable limitations, and VS eliminates that need

entirely.



I don't mind heterogeneity, as long as I don't have to use it. I *like* the

state-of-the-art-in-2006 tools. I remember back in 1979, when I was on the "Spice" project

at CMU, our goal was to equip every researcher with a 3M machine: 1 MIPS, 1 Megapixel

display, 1 Megabyte of memory (you can't sell a machine this small and slow in a

wristwatch today; my PDA exceeds this by two or three orders of magnitude). I know what

we dreamed of as the "ideal" development environment. The problem we had was one of

complete lack of imagination; we still were thinking "cc" and "cdb" styles of programming,

at least an order of magnitude poorer than what I use on a daily basis today. What I find

odd is that this is still largely state-of-the-art in Unix--that is, absolutely NO

progress in development environments in 27 years. Eclipse for C is a serious step

forward, and I've used it. It is almost as good as Visual Studio was in VS4, about 1995

or so.



Yes, I'm a bit of a fanatic. That's because I *love* being productive, which is one of

the reasons I truly despise what Microsoft did to VS.NET and its successors; they took an

*excellent* tool and equipped it with paradigms we abandoned as flawed ideas AT LEAST 30

years ago, and it reduces my productivity. Unlike the idiot designer, I have actually

formally studied issues of user cognition and understand what is meant by "planning

horizon", so when I say VS.NET has a really poor IDE, I have the fundamental theory to

PROVE it sucks. But it is STILL light-years ahead of anything I've ever seen in Unix (at

least up to 2003, the last time I took a serious look, other than Eclipse which I used in

2004 for a while).

joe



On 2 Jun 2006 19:19:19 +0200, Peter <p@nospam.dirac.org>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-