Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Linux IDE from Cygnus 125

Posted by CmdrTaco from the ain't-that-spiffy dept.
An anonymous reader wrote in to tell us that Cygnus is planning to ship an IDE for Linux this summer. It's called Code Fusion and it'll have a lot of competition with CodeWarrior and more already out there. But it will support C/C++ and Java.
This discussion has been archived. No new comments can be posted.

Linux IDE from Cygnus More

Linux IDE from Cygnus

Comments Filter:

  • Re:Why an IDE ? (Score:1)

    by Anonymous Coward
    An ide is an INTEGRATED development environment. They are doing something like the ide in c++ builder, java builder, and visual basic or c is my guess. Linux/unix has many tools not one integrated one, unless you really have to argue for emacs, which is not in the same league.

  • Re:Will It Be Free Software? (Score:1)

    by Anonymous Coward
    Cygnus sells GNUpro, but it's still free software. The fact that they're selling it doesn't mean that it's proprietary.
  • Someone asked about a GUI IDE on a FreeBSD mailing list once, some answered w/ Code Crusader, which is a free IDE.

    http://www.its.caltech.edu/~jafl/jcc/

    take a gander.

    I've never used it, because i've not much of a developer, but I thought I'd point it out so that people see it.
  • I would suggest people to look at KDevelop - http://www.cs.uni-potsdam.de/~smeier/kdevelop/ - although it's for C++ and you'll need QT libraries..
  • Primarily, a company doesn't have the resources to take user calls about 43 distributions, so they pick one. If you use something else, you're on your own.
  • KDevelop 0.4 just came out the other day as well, obviously concentrating on Qt/KDE development. It looks very nice, though. I just haven't had anything to make yet. Somehow, I figure I'll just revert to vi anyway...
  • Since I code C++ on Linux all day long at work, naturally I have a strong interest in good development tools. When I first got started doing Linux programming professionally, I looked at all the tools availible.

    When it comes to IDEs, there's only one good reason, in my mind, to use them: the integrated debugger. Being able to set breakpoints with a single keystroke, run the software, and then when you find the bug modifiy the code right in the same window is wonderful. Compare this to gdb (and this includes DDD, wonderful as it is), where you have to have your source editor up in a seperate window, and changes you make aren't instantaneous. It's also hard to preserve breakpoints across sessions.

    So far, I've tried every IDE that's come out for Linux. That includes Code Warrior, Code Forge, Visual Slickedit, Xemacs, and some others. None have an integrated debugger! What's the point? Project management is the only other major feature these provide, and to someone handy with makefiles that's not really all that desirable.

    So, I continue to use vim+gmake+egcs+gdb for all my work. This is fine, although the debugging does still leave something to be desired. I think an ideal solution would be either to build a very simple debugger front-end into vim (which should probably be a seperate project, to avoid emacs-like bloat in the editor core) which would allow you to set breakpoints and let it run.

    Alternatively, DDD is *very* nice, and with a few interface tweaks (such as customatizable hotkeys for menu commmands - too bad it's not written with GTK) and the abililty to modify text on-the-fly, it could be everything I've ever wanted.
  • The big question here is whether or not this will be free software. The article didn't make it clear and I couldn't find out on Cygnus' web site. Does anyone know the details on licensing?
  • Because Ada is evil and bad.
  • Many small tools is the Unix Way. Why lump everything into a bunch of huge, bloated applications that each try to do everything in a very narrow field, when you can have a bunch of small, efficient utilities that each do one thing well, and can operate on a wide range of data?

    Integration leads to limitation and redundancy. De-integration leads to flexibility and efficiency.
  • I just consider any language that requires you to type "1.0" instead of "1" when assigning to a float terminally brain-damaged. Strong typing is a good thing (Perl's bitten me a couple of times because of its almost complete lack of typing), but typing _that_ strong is ridiculous.
  • Posted by the order of His Majesty:

    Is there no one programming Pascal any longer?
    If there were more people using more programming languages we might not have so many occurances of things like buffer overruns and other misc security breaches... IMHO
  • Honest questions here.

    With emacs/XEmacs, can you:
    Set breakpoints in the source editor?
    When in a "break", can you query various variables, including members of structures? Get a list of the local variables? Cast pointers to other types and query them?
    Mouse-select text for copying and pasting?
    Grab the latest versions of files from source control programs?

    Also:
    Can you add conditions to a break, so it doesn't always trigger?
    Can you syntax color matching parentheses/brackets?

    (Note: I consider the answer yes if it could reasonably be programmed with elisp to do so.)

    The first set are things I can do with IDEs like Visual C++, the second are things I can't get them to do. I find the former really useful, and wish I could do the latter.
  • >GUI design: Look, creating dialogs is not going to be an intellectually stimulating programming task.

    Ironically, GUI design really shouldn't be done visually at all.

    Seriously. A good interface should allow for language differences and user preferences, each of which can screw up your carefully laid out dialogs. The ideal thing is to have the computer lay them out as needed for the user/interface settings, putting the proper spacing, border spacing, etc.
  • Hmm, funny you should mention Borland Turbo C. Although usually I just use an editor and the command line, my favorite IDE so far is RHIDE, which is built on Turbo Vision, so of course it looks just like Borland's old IDEs for DOS.

    Also, you can have multiple windows, compile your code, debug, have lots of hilighting (in the console), jump to the lines that have compilation errors, etc. And it's all integrated, you have your watches, and your breakpoints, and all that fun stuff.

    I guess I just liked Turbo Vision, it was always pretty intuitive for me, which I can't say about emacs. Too many bucky-bits spoil the broth, I guess.
  • Unix is certainly a DE, and a good one at that, but I'm not sure it qualifies for the I. Emacs does, though.
  • "and sell for $299 a seat"

    Can I sit on the floor for $29.95? If I had $300, I'd sit up all night and watch it!


  • -GUI design: Look, creating dialogs is not going to be an intellectually stimulating
    programming task. So do it with a visual editor in 5 minutes, rather than tweaking
    around manually for hours. Then automatically generate the message handlers for
    the dialog and get started with real programming.

    Unfortunately, I generally include at least some element of programmatically generated stuff in my GUIs, and the stuff that I do this way generally is also the stuff that a visual editor would be useful for. For example, a preferences dialog in which items are registered by scripts that get run on startup. (think Emacs' Customize menu and you get the idea..) This doesn't map well into 'visual' design, unless you can show me a visual program that can predict every funky combination of widgets the user will come up with. :-)
    Besides..programming GUIs by hand was a nightmare in Windows but with a sane toolkit (GTK+ and Qt come to mind) I can make a good-looking dialog in a few minutes. That said, I wouldn't be averse to using something like Glade, it's just not worth the trouble. But even without a 'visual' editor, the 'GUI building' is so insignificant a proportion of the time spent on the program that it doesn't matter which I do. (it's not that I don't put thought into my GUIs, it's just that almost everything happens either in the backend or 'behind the scenes' in the GUI -- that is, in stuff that doesn't have anything to do with what widget goes where. Widget placement is the most visible part of an interface but the most trivial thing to do programmatically)

    Daniel

  • I agree that Borland's IDEs (and RHIDE) are pretty good. You could look at RHIDE, or I can give you some quick advice. :-)
    The first thing to remember about Linux programming is that it takes time to become extremely proficient in it. HOWEVER, what this means is 'it takes time to learn to do bizarre regular-expression replacements in your programs that take every invocation of the function foo(int,void *) and change it to the invocation foo(int, bar(int)) where bar returns a void *' Generally you can learn how to get stuff done pretty quickly. In other words, don't panic if you don't learn all 100,000 keybindings of Emacs right away :-). [i'truth, I only know 20 or so, tops, and probably less..same for vi..and I'm an inveterate user of these things]
    Oh, and I recommend picking up the book _Beginning Linux Programming_. It's a useful collection of information on programming in Linux, from tools to APIs. Skip the chapter on Tcl/Tk though, that language must die :-)

    Ok. So. Here are some thoughts about programming with Linux for an IDE:

    -> Info and man are your friends. The info documentation is hard to use with the default viewer though, check out the "pinfo" program which makes info look like Lynx. A lot of documentation is in HTML these days to, you can use Lynx (my preference because of the low memory footprint) or another browser for it of course. Unfortunately, much software has little API documentation (eg, GTK+ and Gnome). If you do much programming for these you'll want to scan the headers a lot...luckily, the functions are usually well-named and commented (not that it makes up for a missing manual)
    -> Learn autoconf and automake at some point. You should probably write at least one Makefile by hand first (to know how much pain you're saving yourself :-) ) and learn shell scripting.
    -> Learn shell scripting.
    -> Find an editor you like. I personally recommend XEmacs and vim: I use XEmacs for 'real' programming and vim when I can't wait 30 seconds for my editor to start :-) Emacs' tab-indent feature, in particular, is light-years ahead of any IDE I've used. Basically, typing 'tab' indents a line correctly for wherever you are. (well, correctly for me..Emacs' idea of indentation coincides with mine quite well. I've heard you can customize it but never bothered) The keybindings are confusing at first, though, especially since some of them aren't necessary anymore (eg, C-something is the same as PgUp) There's a survival guide somewhere.

    But basically, the rule is to learn the minimum amount to do a given task, at least at first, otherwise you'll be overwhelmed. So do this:
    * learn how to use an editor for basic operations (pretty simple unless you're trying vi :-) )
    * learn how to use a compiler (shouldn't be too hard: 'gcc -o foo.o -c foo.c' to make an object file, 'gcc -o foo foo.o bar.o -llib' to link)
    * learn how to write Makefiles

    Once you've done that you can start programming. Intermediate to advanced topics :-) are (in order of importance):
    * shell scripting (not too hard) and the other UNIX tools -- sed, grep, etc. These go together -- one is pretty useless without the other.
    * autoconf/automake (bliss! :-) )
    * libtool (learned this this morning. Not bad if you've done everything else before)

    Daniel
  • I've noticed that generally UNIX users mean something very different from Windows users when they say "integration". Take mail as an example.

    Windows: You have one mail program. Well, probably one. Unless someone else wants to use a different program on the computer. But probably one. It does everything. It receives email, stores it on the system, and sends it via SMTP..and it works most of the time. If you've gotten a really good one, it might even deliver mail in the background and do odd things like Kerberos. If you ever want to switch to another mail client, kiss your messages goodbye unless you convert them to the new format and location; the same goes for any POP settings, mailing list filters, and so on.

    This is an 'integrated' program; all functions are in one place.

    UNIX: The mail system comes in pieces. There is a mail delivery program, which takes mail and sticks it somewhere, a mail getting program, which speaks POP and all its variants, a mail client which reads one of a few mailbox formats (mbox and mh), a mail editor, and a mail transfer program. [some clients pick up, eg, the editor, but they usually let you use a different one] other mail-processing utilities may be installed as well.
    When you receive a message it is either sent directly to the delivery program via SMTP or gotten by fetchmail and then sent to the delivery program. The delivery program then either passes it to another mail-handler (procmail for example) or else delivers it directly to a mailbox. All (or most) mail clients read and write the mbox format, so any one can be used to access the messages. This means that changing mail clients does not require you to give up your history of correspondence, and since the mail client doesn't even handle POP and so on those naturally are also preserved. When you send mail, the mail client passes it to the mail-delivery software, which spools it for immediate or deferred delivery. The mail client need not be running while the mail is being delivered.
    Each of these programs generally is highly specialized and most users will only touch from five to ten percent of the features (not, please note, the same 5-10%)
    This is an integrated system: it has many pieces which work closely together to produce a finished result.

    Ok. Back to complexity. :-) It would seem at first glance that the second system is more complex. This is not true, or at least not in the way you implied -- that it requires lots of 'getting your hands dirty'. There is more obvious complexity in the second system, but it is carefully contained. Each program is internally complex, but communicates with the others through (relatively) simple and well-defined interfaces. The first program looks simpler because there's only one obvious thing to consider, but it is more difficult to design and less flexible (because one group probably wrote the whole bloody thing instead of multiple independent groups concentrating on discrete, small bits of code and because you can easily isolate each piece of the system..this works both conceptually -- I can understand how fetchmail works without caring about how the POP server or the local mail delivery agent work -- and from the point of view of actually doing things: any piece can be replaced with a better one or reconfigured in bizarre ways if necessary)

    Hmm. I had a point here but I ate supper in the middle and lost my train of thought. :-) But basically, my experience is that things people think are 'simpler' (like designing everything in one piece, or writing quick-and-dirty routines) generally turn out to be more complex (in the bad sense) in the long run. Witness the amount of time and effort spent designing defragmenters, disk checkers, virus scanners, memory protection libraries, etc for DOS [aka "Quick and Dirty Operating System"]. But as they say in these parts..YMMV.

    Daniel
  • I concur. KDE looks very promising. The document generation features and the auto-generation of all the GNU autoconf stuff are really nice features.

    Ando of course it isn't just limited to producing KDE-specific applications, you have a choice of KDE apps, QT apps (which would be portable to Windows) and generic C/C++ apps.

    Nick

  • Not quite. Cold Fusion, for one thing, is a scientific process, Allaire's trademark is at best restricted to a Web application platform. Plus, they'd have a difficult time convincing people that they own that term. Prior art? People have been investigating cold fusion chemically, for a long time.

    Plus, they'd have to conclusively prove that Code Fusion dillutes the trademark... I'm surprised they even managed to get one.
  • I realise this was a joke, but the pedant in me cannot be denied:

    What keeps it from being GPLed now? Not that I think it will be, but what about the fact they are charging money for it keeps it from being GPLed? Why continue the confusion between Gratis and Libre?
    --
    "First they ignore you.
    Then they laugh at you.
    Then they fight you.

  • Code Forge has Ada support. I use if all the time for Perl, PHP, and HTML.

    http://www.codeforge.com/features.html
  • For *BSD you'd probably use the excellent *bsd
    linux emulation.
    (I'm a linux user, but I was impressed)

    Solaris ... I dunno.

    Sco... ibcs?

  • Argh!!! (Score:1)

    by Bwah ( 3970 )
    Why doesn't anyone make and IDE or code browser that supports ada!!!! Source Navigator from cygnus rules, but still doesn't support ada. Life is unfair.

    /dev
  • I couldn't agree with you more that is is evil. Bad is debatable. However some of us poor bastards are stuck with it ... and will be stuck with it for some time.

    /dev
  • I really want a ada code browser/IDE. Something that will let me click a symbol and see the definition, etc. Lots of editors support ada for syntax highlighting. (Although most don't run on VAX VMS ... so i'm still screwed. just gotta live with EDT and LSE I guess)

    /dev
  • There is a reason that until now all DoD work was required to be done in ada. The strong typing and wanna be object orientation (in ada83 anyway, ada95 really is OO) make for some pretty stable software.

    There is nothing inherantly (sp) better about ada, when compared to C for example, but the way it tends to work is that if your ada software makes it past that %$#@$#@* compiler it will more or less do what you wanted. usually. well sometimes anyway. Overindexing arrays and such is harher to do in ada. If you use a real ada run time it's really hard, but full blown run times are slow and eat eeprom like popcorn.

    The catch is that it is easier to really tweak out your software in C. I'm fighting a problem right now at work where I could do something in C with extreme ease and effiency, but in ada it's very very hard to even come to the same elegant solution. Granted some of this is due to the DoD coding standards where I'm at being kinda strict. (read as kind of freaking brain dead is many ways!) But these do tend to lead to more reliable software, and lord knows when you creating a product that has destructive potential you want it to be reliable.

    I'll shutup now. gotta go barf out some more ada code on my super duper VAXStation 4000-60. fun fun.

    /dev
  • But an IDE can lessen the learning curve for newbies and allow for more people to get interested in making applications for this platform.

    Today's English Lesson: Oxymorons

  • mary jane......

    from the earth, up through the trees,
    I can hear her calling me
  • Dude,
    vi is too bloated.
    I'm writing my own editor at the mo. It will have load, save, find/replace and block copy.

    That'll do nicely.
    And pigs will fly, or something....
    PS don't drink and code...
    bleh
  • Hey, I would buy your IDE. So when does it come out? :-)

    Honestly, VC6 is a pretty slick programming environment. I just wished that it wasn't that integrated, so you could exchange editor, debugger or compiler.
  • Sounds like Cold Fusion with bad sinus congestion... Is this a deliberate take on the Code Fusion name?
  • Not to start any flame wars (yes, multiple vi's in xterms works too), but emacs is my preferred IDE. I started off programming with the Borland TurboC IDE. It was OK, but when I got to college and had my first exposure to emacs, it was a marriage made in heaven. I can have multiple windows, compile my code, debug, have lots of hilighting (in X), jump to the lines that have compilation errors, etc. I've even gotten a lot of my coworkers using emacs (well, XEmacs), and they seem to like it a lot.

    Yes, there ARE other ways to do it, but this works best for *me*. Everyone has a choice.
  • I don't think- I saw this earlier today (news.com, I think) and it will be $299 a seat.
    ~luge
  • It seems to me that high quality IDE's seem to be geared to a very small subset of programming languages.

    While this can be a good things, as to allow you to easily prototype a working program for testing using their visual components (VisualAge, JBuiler, VisualCafe, Visual Basic et cetera). I believe that it hinders one by having to use and install multiple IDE's in order to write in different languages.

    From what I have been able to determine, even as a student, is that no language is perfectly suited for each and every task. PERL is excellent report extraction and analysis, and is extensively used in CGI, JAVA makes a nice powerful GUI, C/C++ are excellent for very large scale projects and low level programming (simply my views)...

    This brings me to my point. Let us assume that one is pro efficient in PERL, Java, C/C++ and Python. Now VisualAge is a nice package for Java, so we install and learn that, then we install CodeWarrior for C and C++, and then one for PERL and another for Python.

    Each and every single one of these have a different look and feel. Sure, it can be associated to it's object oriented nature, but VisualAge is considerably different from any other IDE that I have seen for handling classes and methods. This seems rather odd, that I have to learn how to use multiple interfaces, simply to gain quick prototyping and a nicer looking development environment.

    I would find it very nice to have a complete development environment suite. Possibly in plug-in form that would allow us to programming multiple environments using the same IDE. Sure some of them would not allow for visual prototyping (even PERL could using the CGI mod), others may not have to be compiled simply executed and debugged, yet one interface to learn and to master is much better then two plus.

    I know some will mention VI and Emacs... I have nothing against them, but I highly doubt that I can sit down, and write a JDBC enabled piece of software with everything linked visually. Either way those are my views.

  • Good news, but IDE's are a mixed blessing ... (Score:4)

    by LizardKing ( 5245 ) on Friday June 18, 1999 @06:54AM (#1844209)
    I applaud Cygnus Solution's decision to release an IDE for Linux, and I hope it attracts new coders to the platform. However, I've always found IDE's an anti-climax on any platform. The amount of time I expended on learning the quirks of another editor, key bindings for compiling, etc. was never rewarded by increased productivity.

    While an editor like vi or emacs, and a debugger like gdb may look daunting to new users, learning them is far more useful than learning an IDE. The IDE has one task - providing a frontend for development. A standard Unix editor (and this includes GUI ones like Nedit) is far more rewarding to learn, as it can be used for more general tasks than programming.

    I've seen some IDE's that allow the user to specify which editor to use for code-editing. This really invalidates the IDE concept, as the while point of an IDE is to provide integrated tools, but they can't be relied on to support the features of vastly different editors.

    Another gripe about IDE's is that they usually employ wrapper utilities for programs like make and gcc. This is fine until something breaks. Having done some of my programming on Windows NT 3.51, I can honestly say that those who learn programming in VC++ are stumped when the IDE 'breaks'. They are unable to grasp the fact the VC++ is just a frontend to a make utility, command line compiler and debugger. When VC++ failed to work on a project file, I simply edited the make file by hand and compiled from the command line. My co-workers didn't have the first idea about how to do this, having learnt to code on VC++ or Borland IDE's.


    Chris Wareham
  • CodeWarrior will run on distributions other than RedHat. We (Metrowerks, that is) even give instructions on the CD for installing by hand if you choose not to use the RPM provided.

    I've been able to get CodeWarrior to run on all of the distributions I tried so far which are RedHat 5.2, RedHat 6.0, SuSE 6.0, SuSE 6.1, Debian 2.1, Caldera 2.2, and even FreeBSD 3.2! It's not always easy to get it to installed and running, but it is possible.

    Our "Red Hat" product was QA'd on Red Hat 5.2. We do plan to validate CodeWarrior on other major distributions for future products.
  • What are the odds of us seeing ports for FreeBSD, Solaris, and DEC UNIX/Tru64?
  • MIS

    Simon
  • Maybe my projects just haven't been big enough to need an IDE. A couple of xterms (one for vi, the other for make) have always been enough for me. Being a starving student still, the $300 that the article mentions is just enough that it's hard to justify.
  • Doesn't the "per seat" imply that it is not open source? If it was, then you could make your own binaries and run as many copies as you please, couldn't you?
  • Why don't you be a man and just use those switches on the front of your computer.
    --
  • I think he meant free as in freedom, not price.

    Will it be free software?

    Alejo.
  • I think he meant free as in freedom, not as in gratis.

    Is RedHat free? Yes? But doesn't the web site say something like $49?!? Glad you got the point. :)

    Alejo.
  • Why don't you?!

    Alejo.
  • Do you get tired of writing all those extra .0's, or are you afraid you might get out of disk space?


    A programming language (these days) has to be designed to ease the work of the programmer. Having to type all those '.0' can be a real pain. I suppose it is just a thing of getting used to it. So I suppose both of you are right and we could bitch about C too for many things if we weren't so used to them.

    Alejo.
  • Well, you can still charge for free software. I know, not "per seat", but the fact that they are charging $249 does not mean it is not free software.

    Go to http://www.redhat.com/ and see how expensive it is. And it is still free software.

    Alejo.

  • For these reasons I feel a Linux standard is needed; otherwise developing for "Linux" will be too much of a pain for companies and it won't really happen. If not that, then software development companies will all eventually gravitate toward one proprietary version of Linux, and we'll have the Micro$oft effect all over again; the oppressed will become the oppressor.

    Not really, some distros may have to become 'compliant' (at worst). Say you have debian and you need to run some 'RH Only' package, debian would, I suspect, have a RH-Emul package you could install.

    The only way I see this really happening is if some distro contained something truly closed and proprietary. I just do see this happening any time soon. Besides which, what kind of brain-dead company would choose to only develop for some proprietary feature in an otherwise free/open OS? I suspect we don't need that kind of hypothetical software anyway (How wonderful could it be, given the already short sightedness of creators?).

  • HUH? (Score:1)

    by Wiley ( 14529 )
    Obviously you haven't worked on any large programs... if you had, you can see why a graphical IDE is so much more valuable than using a text based editor... (for the record, I've been a developer for ten years and worked on a number of large projects... emacs does some great things, but it does hurt my eyes after about 12 hours of solid coding...)
  • Code Crusader and Code Medic are wonderful programs that integrate well. I really like them. Especially the front end to gdb

    However, I'm really looking forward to the development of gIDE which will allow easy building of GTK apps.

    I don't see why anyone would really want a commercial ide for "at home" projects. There's too many good ones out there already, and quite honestly...not many people need all the extra features the commercial ide's have to offer. The commercial products might be much more useful for commercial multi-concurrent-developer projects and the like.

  • How well can, say, VisualC++ do the above? (I'm really asking, as I haven't used it.)

    Very poorly. I was entirely unhappy with Visual C++ for large projects (>100,000 lines of code). It doesn't even do well when, for example a 500,000+ line project is divided into smaller executables which are each in the 3,000 to 50,000 line range (not counting of course common library code).

    It is no fun trying to set up Visual C++ to rebuild things, for example when you make changes to a common library function and now have to open up several dozen projects, edit them and rebuild. You really need a good scripting tool to do that, and Visual C++ wasn't designed to play nicely with scripting tools.

    For me I'd much rather use a UN*X-like environment for large scale development. Thankfully, I can pretty much pick and choose what I work on, so I am lucky enough not to have to deal with Visual C++ anymore.

    And don't even get me started about things that are agregiously broken with Visual C++ like lstrcpy(), lstrcat(), etc...

  • Depends how you use it. Projects I work on are always cross-platform, usually some variant of Unix and NT.

    The projects I used to work on when I was subjected to NT were usually cross-platform, although few started out that way. Some started out on *nix, and some on Windows. I did most of the work to make the code portable. I was often working with code that I hadn't written at all.

    What we do is create an include file that lists the source files, a makefile for the Unix side, and a makefile.mak for the NT side.

    I ended up scrapping M$'s make and using a port of GNU Make for Win32. M$'s make not only seemed to be a cruel joke, it also seemed to be a moving target (changed between versions of MSVC and the automated conversion usually failed). Later on I switched to using Watcom (Powersoft) C/C++ for Windows compiles, as it has significantly better cross-platform compliance (working strcpy(), strcat(), opendir(), readdir(), etc).

    The top-level makefile has targets that invoke each of the subdirectory makes. The most likely thing to burn you is that it's natural to use the directory names of the sub-projects as the names of the top-level make targets, and that doesn't work (changing the source files always updates the timestamp of the directory, so M$ nmake doesn't chase down the sub-project build.)

    I've seen wacky things like that happen. I am glad I don't have to deal with it anymore.

    On NT, create a top-level project using the existing makefile.mak, and sub-projects for the subdirectories. You can select your top-level project to build everything, or individual sub-projects as necessary.

    Personally I just use MSVC for debugging -- I do the actual builds using command line windows and the MKS utilities.

    That sounds kinda similar to what I ended up doing. You almost have to have something like MKS, albiet even with a lot of add-on utilities, I could never really get an environment under NT I was happy with.

    Setting up the whole project under MSVC and then trying to port to cross platform makefiles takes much more time than starting with your own makefiles and wrapping M$ project files around them -- the makefiles generated by MSVC have platform-specific directives and really don't look much like makefiles if you let MSVC manage them directly.

    If you use their generated files, they don't seem to be intended to be human readable at all.

    I gotta admit -- M$ IDE is far, far ahead of most Linux/Unix tools for debugging.

    M$'s IDE is far flashier than most of the free tools, but I am not sold on its overall functionality. More often than not, my experience with the MSVC debugger was that errant code either froze the whole machine, blue screened the machine, or crashed the debugger. In other words, it was worse than useless.

    Kind of irritates me that *nix platforms still haven't got such functionality unless you look at the multi-K$ price range,

    For work, multi-K$ prices aren't that big an issue. M$'s 'Enterprise' versions of their tools aren't all that cheap either. For my outside work I do at home, M$'s tools are just too expensive. I can't justify spending $3,000+ for NT+MSVC+MKS+ other 3rd party tools versus what I get when I buy a $50 box from SuSE.

    and even then only if you've got a truly obscene amount of memory so that the multiple debug and executable processes don't thrash themselves to death.

    I use SparcWorks at work, it has a debugger I like a lot better than that in MSVC, and it runs fine on an Ultra 5 with 128M of RAM.

    Yeah, yeah -- xdb, dbx, gdb, yada yada -- I've got several years experience with them, and only 2-3 years with MSVC, but it only took 6 months to convince me the M$ debug environment was a much cleaner solution.

    I spent a year with MSVC, and it convinced me that I never want to do development on Windows again.

    It gets really addictive to be able to step-trace through code as quick as you can hit the function keys, rather than waiting for the 0.5-2.0 second lag with the *nix debuggers,

    I've never noticed that kind of lag.

    and I have found nothing under *nix that lets me set watch points over memory regions the way I can with MSVC

    SparcWorks debugger has a feature like that, I've seen a similar utility on IRIX, but that was quite some time ago.

    (nothing else is anywhere near so handy for tracking down that rogue piece of code that's overwriting memory it shouldn't be touching!)

    You might look at Purify and Electric Fence.

    Big projects? Currently working on one that's well over 500K lines, expected to exceed 1M during the next year. No debug problems on NT or *nix so far, other than the ever increasing memory requirements during debugs -- and the ever decreasing screen space.

    Most of the projects I work on these days are smaller (less than 200,000 lines), and I no longer have to do any Windows development, so all is happy for me.

  • BZZZZZZZZZZZT!

    Wrong!

    Free(d) Software / Open Source != Freeware
  • hmmm....the article says $299 a "seat"...If I stand while I code, will they GPL it? :)
  • When I started programming, it was with IDE's.
    I couldn't imagine vanila text editors being
    much fun. Then one day I decided I had to
    use DOS instead of Windows for this Project.
    My IDE was windows only.

    So I found me a nice programmer's editor,
    wrote and a makefile. And I found it no
    less efficient. Now under linux I don't
    even need a powerful editor.

    I have been told that modern GUI's give
    better milage than my old one (Borland 4.0).
    But at the end of the day productivity
    improments come from good code, good languages,
    and most improtantly good APIs.
  • I use vim, but I still use multiple xterms
    (or VTs). I just find it easier that way.

  • The article was quite clear about it:

    It will ship in mid-July and sell for $299 a seat, says the company, based in Sunnyvale, Calif.

  • Nah, emacs is for people who don't have the brain to learn more than one program.

    (Starts donning asbestos underwear....) :-)
  • Once you've developed for one Linux, you haven't developed for them all. There are significant enough differences between the various avatars of Linux that not all binaries will just run on all Linuces. In fact, one source tree may not even compile on all Linuces. So it isn't just a matter of whether one is familiar with each type of Linux or if the package type is different, or that someone just signed an exclusive contract (sorry, I had to say it).

    The switch to glibc 2.1 caused unexpected problems for us. SuSE is a very different animal from Red Hat, in terms of certain libraries and where they are located, among other things.

    For these reasons I feel a Linux standard is needed; otherwise developing for "Linux" will be too much of a pain for companies and it won't really happen. If not that, then software development companies will all eventually gravitate toward one proprietary version of Linux, and we'll have the Micro$oft effect all over again; the oppressed will become the oppressor.
  • One more thing Emacs can do -- Win32!

    I use Emacs as an IDE from the Cygwin compiler/tools on NT 4.0. MUCH easier going back and forth from Linux to Windows if your key bindings are the same. Check it out at http://www.cs.washington.edu/ homes/voelker/ntemacs.html [washington.edu]

  • Well, I suppose I'd have to agree with you about the state of Java GUI design. And, luckily, Java is a lot easier when it comes to writing GUIs by hand, especially in terms of the variety of layout managers (though all of them are still fairly annoying). I found some use for JBuilder, but its layout facilities were not up to par.
    I'm actually a big fan of VC++'s visual layout. Fast, easy, excellent for adding member variables and functions to go with components. And, as with JavaBeans, ActiveX controls can be added visually even if the IDE has never seen them before.
    In terms of code resuse, I certainly agree that VB doesn't promote it. Too many properties, not enough methods. It's just not OOP.
  • Try KDevelop. Still alpha, but it does integrate Kdbg for debugging. Also has a dialog editor, class browser, syntax highlighting, project management (all this in version 0.4!).

  • Re: IDE Bashing (Score:3)

    by JohnZed ( 20191 ) on Friday June 18, 1999 @10:03AM (#1844236)
    There are three valid uses for an ide:
    -Class browser: See a tree with all the classes/members in your project and just hit one click to take you exactly to a method definition. Or view a graphical inheritance tree.

    -Syntax completion: If you're just doing straight Unix C systems programming, no GUIs, and you have plenty of experience, sure you only need to look up the occasional command. But if you're programming against a massive GUI API (Windows, KDE, etc.) with a class library that you didn't write, syntax completion is key. Who the hell knows all three overloaded forms of some obscure command to manipulate a tree control? Who the hell really wants to? An IDE will pop up a parameter list for you instantly.

    -GUI design: Look, creating dialogs is not going to be an intellectually stimulating programming task. So do it with a visual editor in 5 minutes, rather than tweaking around manually for hours. Then automatically generate the message handlers for the dialog and get started with real programming.

    Good IDEs can make a serious productivity difference if they're used for the right tasks and if you KNOW HOW TO USE THEM. There is very much a mindset to each IDE, just as there is to Emacs, vi, etc. If you approach Visual C++ by thinking of it as just an even bigger, slower version of emacs with different keybindings, it will do you know good. But if you think in its visual terms, you'll get a lot more done.
    I personally think that programmers should be comfortable with both text editor/make and visual/IDE programming. It sharpens your skills when you come at a problem from a different angle.
  • Done right, a UNIX IDE would consist of:

    1. a replacable editor component, your choice of emacs, vi, etc. compatibility (or better yet, emacs or vi themselves seamlessly integrated)

    2. a replacable DDD-ish debugger component with graphical and command-line capabilities

    3. a project manager that maintains a human readable Makefile, possibily layered on automake

    4. gcc

    All of it tied together with CORBA component objects, like the GNOME or KDE COMs.

    At least thats how I would do it.
  • Remember to start the debugger first: M-: gdb

    Set breakpoints in the source editor?
    Yes: C-c C-b

    When in a "break", can you query various variables, including members of structures? Get a list of the local variables? Cast pointers to other types and query them?

    Yes: print
    You can also call functions from the debugger (e.g. print strlen(foo))

    Mouse-select text for copying and pasting?
    Of course.

    Grab the latest versions of files from source control programs?
    See Version Control in Emacs Info.

    Can you add conditions to a break, so it doesn't always trigger?
    Yep: condition in gdb. You can do this in VC++ by going to Edit/Breakpoints and setting the breakpoint properties (warning -- slows things don't to a crawl).

    Can you syntax color matching parentheses/brackets?
    Hmmm, don't know. Possibly. Emacs does the flashing cursor brace/bracket/paren matching which is enough for me.

    You can set Emacs key-bindings in VC++, too. It is hidden away under Tools/Customize/Compatibility. Set the current source editor emulation to Epsilon (a windows/DOS emacs-like editor).
  • An IDE is more than a build tool, it's a development tool. For example, in VC++ you can
    easily visit all defintions/references of an identifier. You can approximate this functionality with grep, but it's not as convenient.
    Personally, I don't use VC++ to manage builds of multiple projects; for that I use make. The idea is to use the most convenient tool for the job.

  • A UNIX DE is not a bad idea. I've been using emacs for years, but I don't use its debugger interface: I prefer DDD. If a tool helps me, I use it.

    Likewise, it would be handy to get hold of a slim and capable editor, a gifted debugger, GUI builder, makefile manager, class/object browser, etc. as a suite of development tools. But that doesn't mean that you can write a single ugly application that makes kludgey auto generated code and doesn't give you full control, numbing you with silly conventions. They call that Visual C++, if you're fond of that join MS Developer Studio team and be shadowed under curses of a thousands developers every day.

    I believe that there are a couple of guidelines to follow. For instance, the infrastructure is more important than the looks. In order for the tools to communicate, they should have CORBA (or an appropriate object model) interfaces. In other circumstances, they should be usable as standalone applications. So you can have your editor-of-choice that works with the rest. The compiler and debugger interfaces must be well defined, as well as binary format handling; I think the standard GNU tools will do.

    The DE must not be focused on a single language, for instance the "type browser" must work equally well for both C++ and Scheme. No need to mention that support for a new language should be as simple as a plug-in.

    If a tool is calling a command line program, it must supply a complete interface. That is, one that gives ultimate control over the tool: without omitting any options or functionality, and indicating the mapping clearly. So a front-end for gcc options must be pretty articulated. Of course, for makefile management, as an example, I think there might be multiple back-end choices. So the design can take that into account.
    [Don't know, make it OO and derive subclasses.. Separate interface/implementation so that the framework is not tied to a single CLI]

    There are many other things to worry about, but I'm out of ATP. After all, you'd like something that works and give you a good speed-up.

    Unfortunately, there is no such thing in UNIX. I haven't seen it and I don't believe that it exists. :) Hope remains that some people are going to start it as part of the GNOME project. Perhaps, we would have something if GNUSTEP was somehow complete. Until then, I have my terminal windows, emacs and ddd.
  • Uh-huh ....

    KDevelop is probably what you'd expect from an IDE on Linux (yes, it's free).

    It's still in alpha, but it works fine on SW 4.0, RH 6 & 5.2, Debian 2.1, and Stampede 0.89.

    Note on Stampede: I really expected more speed out of KDevelop, but apparently K in general is still rather klunky. And personally, installing all the packages was a REAL hassle.


  • "Obi-Wan has taught you well, but you are not a Jedi yet."



  • It seems that now that most people can use an alternative operating system, they still won't use an alternative programming language. Very understandable, most people have taken classes in C or C++ and have mastered the language. Even though the flaws of C or C++ have been pointed out time and again. I think using an alternative programming language would be good, even if just to broaden your scope as a programmer.

    I've been looking for a programming for myself as of late. I haven't taken any real classes in programming so I have sort of a disadvantage. I have mastered QBASIC before I knew what I was doing. Now I am looking into languages like Forth, Dylan, Eiffel, or Lisp to find the right language for me. I tried C before but I really don't like pointers (Okay, so I am a lazy BASIC programmer). Pascal is very elegent but at a point they just tack on features such as file pointers or object oriented programming without being consistent with the rest of the language.

    The nice thing about Linux is that I have these kind of choices.

    --

  • Im looking into various programming languages and am wondering what is wrong with Ada?

    --

  • There a team working on a Pascal IDE for Linux -- check it out at The Megido Project [megido.org].
  • Being force to type 1.0 instead of 1 might be
    annoying, but its nowhere near as bad as
    searching for a bug in C code caused by eg.

    float x = 5/2;

    assigning the value 2.0 to x.

    And believe me, a lot of people who think they know C do make this mistake.

  • C-Forge ( http://www.codeforge.com [codeforge.com]) is close. Not perfect, but close.

    • It uses unix tools, like gcc for C programming (It supports abt 20 programming languages. I use it for Java, Python and C) and DDD for debugging.
    • Everything is configurable.
    • It's project manager uses standard Makefiles

    It does use it's own editor, tho.

  • Is there no one programming Pascal any longer?
    No.
    If there were more people using more programming languages we might not have so many occurances of things like buffer overruns and other misc security breaches... IMHO
    I agree. That is one of many reasons I have rejected C and startet writing in Ada95. Personally, I would require a lot more than average payment to start writing in C again. I recommend taking a look at Ada. The following resources are pretty interresting:

  • I just consider any language that requires you to type "1.0" instead of "1" when assigning to a float terminally brain-damaged. Strong typing is a good thing (Perl's bitten me a couple of times because of its almost complete lack of typing), but typing _that_ strong is ridiculous.
    Do you get tired of writing all those extra .0's, or are you afraid you might get out of disk space?

    That is a microscopic detailt. Saying this is near eqivalent to saying "Norway is hell. I just consider any country where milk is sold in cartons terminally brain-damaged. So I stay in Kosovo".

  • Fearing you might be correct, I looked up the "I" word. Webster's Unabridged (1989) says "integrate" means to bring together or incorporate parts into a whole, which definition would tend to back you up. OTOH, "integratED", once you get past the religious/ethnic group thing, has to do with "combining or coordinating separate elements so as to provide a harmonious, interrelated whole", or "organized or structured so that constituent units function cooperatively", which I read as applying perfectly to the way unix tools talk to one another with pipes and structured text. OTGH, I suspect I'm preaching to the converted here :-P
  • ...just not a graphical one. I wonder how many people at cygnus use emacs or vi and how many use code fusion?
  • That is an insightful comparison between the DOS/Windows design model and the Unix model.
    For the IDE to reflect the Unix model - and thus be widely accepted by the Linux community it will have to allow a great deal of customization and the ability to act as a front end to an array of interpreters and compilers. Perhaps it will allow you to load the language support in modules to keep the IDE's footprint relativly small.(I certainly hope it won't require a minimum of 64MB of RAM to run at a respectable speed.)

    Just my redundant 2 bits.
  • ...this looks out of place, but who am i to question goddess.

    nmarshall
    #include "standard_disclaimer.h"
    R.U. SIRIUS: THE ONLY POSSIBLE RESPONSE
  • I haven't tried CodeWarrior yet, but I suppose the reason they released it with support only for Red Hat is because the installation must be in RPMs, and not tar.gz or .deb, or whatever other format...

    You can still install it on other distributions, but RPMs on some distributions are sometimes tricky (i.e. don't work all the time unless you set it up perfectly). I had this problem once with an old version of Debian!
  • I think that Allaire [allaire.com] might possibly have a problem with Cygnus' choice of name.

    --

  • Why? They're different names?

    Doesn't matter. Besides, they're not *that* different.

    "CodeFusion" could still be deemed to be an infringement of the "ColdFusion" trademark if it is determined that they are confusingly similar.

    This will be especially true when Allaire releases a version of ColdFusion for Linux.

    --

  • Depends how you use it. Projects I work on are always cross-platform, usually some variant of Unix and NT. What we do is create an include file that lists the source files, a makefile for the Unix side, and a makefile.mak for the NT side. The top-level makefile has targets that invoke each of the subdirectory makes. The most likely thing to burn you is that it's natural to use the directory names of the sub-projects as the names of the top-level make targets, and that doesn't work (changing the source files always updates the timestamp of the directory, so M$ nmake doesn't chase down the sub-project build.)

    On NT, create a top-level project using the existing makefile.mak, and sub-projects for the subdirectories. You can select your top-level project to build everything, or individual sub-projects as necessary.

    Personally I just use MSVC for debugging -- I do the actual builds using command line windows and the MKS utilities. Setting up the whole project under MSVC and then trying to port to cross platform makefiles takes much more time than starting with your own makefiles and wrapping M$ project files around them -- the makefiles generated by MSVC have platform-specific directives and really don't look much like makefiles if you let MSVC manage them directly.

    I gotta admit -- M$ IDE is far, far ahead of most Linux/Unix tools for debugging. Kind of irritates me that *nix platforms still haven't got such functionality unless you look at the multi-K$ price range, and even then only if you've got a truly obscene amount of memory so that the multiple debug and executable processes don't thrash themselves to death.

    Yeah, yeah -- xdb, dbx, gdb, yada yada -- I've got several years experience with them, and only 2-3 years with MSVC, but it only took 6 months to convince me the M$ debug environment was a much cleaner solution. It gets really addictive to be able to step-trace through code as quick as you can hit the function keys, rather than waiting for the 0.5-2.0 second lag with the *nix debuggers, and I have found nothing under *nix that lets me set watch points over memory regions the way I can with MSVC (nothing else is anywhere near so handy for tracking down that rogue piece of code that's overwriting memory it shouldn't be touching!)

    Big projects? Currently working on one that's well over 500K lines, expected to exceed 1M during the next year. No debug problems on NT or *nix so far, other than the ever increasing memory requirements during debugs -- and the ever decreasing screen space.
  • If you use GDB (the GNU debugger), you can integrate it very well with Emacs and do most of the things you ask for. Look at the info page for GDB (C-h i); it has an Emacs section that says how.

    Emacs has long had parenthesis highlighting, by the way.
  • Integration leads to less complexity, allowing us to tackle more complex concepts. Yeah, we're hackers and we enjoy getting our hands dirty, but we stop messing with the details at some point, be it at the source code level, the bit level, the hardware CPU level, the transistor level, or lower.
  • Well it's certainly about time that something like this came out from Cygnus...since the administration of our University seems set on the idea that we need something like Codewarrior to code, at least we can have something almost USEFUL.
  • Don't forget cscope.
  • > Why continue the confusion between Gratis and Libre?

    Because they like to screw with people's minds. "Free" quite simply means gratis in virtually everyone's minds, and everyone knows this. The word you want for libre is "hackable". Until they figure this out, they'll continue to hurt themselves.

  • I know some will mention VI and Emacs... I have nothing against them, but I highly doubt that I can sit down, and write a JDBC enabled piece of software with everything linked visually. Either way those are my views.
    Then something is fundamentally wrong with the design of that system that its complexity should exceed mortals' ken.
  • but the fact that they are charging $249 does not mean it is not free software.
    One can continue to repeat clever sophistries until the sun goes nova, and continue to be very clever, very punny, even technically correct in at least one particular circumstance. But one is still completely misleading to virtually all the world.

    Just yesterday, I was asked by a regular person, not even a kid, whether [random software] was `freeware, or just shareware'. See that? Here's a simple test. Go out and ask 20 teenagers whether free software (which they'll call freeware) ever costs anything, and you'll find that 100% of them say, `What, are you crazy?'

    Let's face it. We've lost this battle. We have to stop hurting our own goals by beating a dead horse. We must instead use a real word in the way that everyone understands it. Of course gratis and libre are lovely distinctions, pero por desgracia, ocurre que todo el mundo no entiende castellano. :-)

    Instead of gratis, perhaps we should say cost-free. See how clean and simple, how unambiguous that word is?

    Instead of libre, we might say something more like hackable; that's my own original preference, but it has its own attendant difficulties. Less charged alternatives include changeable or mutable or legible or open source or as source code or in some cases, perhaps unrestricted. Historically, we used freely redistributable as distinct from public domain, but that's a problem term because it has the `free' bug, and doesn't specify source code.

    I may not be certain about what the right word is, but I'm completely certain what the wrong word is. The wrong word is `free'. Please, please, PLEASE drop these teen-age word-games that only cause everyone on the outside to get confused just so that those on the inside get to gloat about how much smarter they are than the rest of the word. It's long past time to face the fact that we've lost the battle for this word, and perhaps time to realize that it was always the wrong word right from the get-go.

  • I totally agree. IDE's are not all that they are cracked up to be. However, I see this as good for Linux in three main ways:
    1.) Linux will be taken more seriously as a developer plaform.
    2.) If it takes off that way software(in theory) would cost less to develop b/c of Linux's free nature.
    3.) As you stated, people that code with heavy assistance from IDEs can now develop in Linux meaning a larger programmer pool.

    The last item is either good or bad. Perhaps it is better that only those that truly know how to program are writing code in Linux. After all, not just Win32 itself is responsible for apps crashing.

    Conversely, it could be good. Think of it as a domino effect--People of all coding abilities could be drawn to Linux and create and contribute. Given Linux's community and software peers, we pressure to keep open source and as a result can better others' shotty code. Still, there is no excuse for writing bad code in the first place.

    The bottom line is that IDEs can be really good for Linux. Granted, there is no excuse for getting addicted to anything, i.e.: IDEs and even HTML editors. People could write worse code but as long as Linux keeps the open source attitude, we can pressure them to get it right.
    -Clump
  • What, a mouse is too hard to use? People don't build their own VCR's they just want to use them. The same goes with computers and their applications.

    I think writing a decent UI shows more ability than typing at a command promp circa 1981. Having the power of linux controlled from a consistant and easy to use frontend would be decent.

  • Yeah, them and those pesky high-level languages.

Slashdot Top Deals

"Now here's something you're really going to like!" -- Rocket J. Squirrel

Close