Specifications of the IDE and compiler

[Parker]

Because of some of the tools I'm writing, I've been wondering about a couple things
- What are the structures the IDE uses for projects and .opts files?
- What are the available compiler options?
- Where does the compiler store the list of libraries that you specify in #use statements?

The linker, assembler, resource compiler, and ar tool have plenty of help on the command line or through online docs, but the compiler (also ibparse) I've always wondered about, and I seem to have lost the post that told the IDE's project structures. I'll also need to load the .opts files.

I don't need much explanation, just the structures, they don't need to be converted, a brief explanation of the compiler options and where the #use list is stored.

Thanks
Parker

[Ionic Wind Support Team]

All of which is preliminary and will definiately be changed before release.  The project file format will always be backwards compatible with the current alpha, but I have a lot being added to it.

The .opts file format will definately change in the next few updates.  Have to store bookmark information somewhere  

So you are better off waiting a little while.

[Rock Ridge Farm (Larry)]

Are these tools possily the beginnings of a RAD for Aurora?

[Shannara]

Im going to have to dink around some more with Aurora. But, I remember Paul, you answering my question on whether the IBasic IDE is really an IDE, and according to your answer, it wasnt, just a bolt copy & Paste from the dialog editor to the code editor. Have this been fixed for Aurora, or the same thing?

[Parker]

So far the tools contain a pakgen type program, it'll be written when a compression class is added, and the "Aurora easy compiler" that will handle building programs and projects from a single command instead of tons of different commands.

The easy compiler is what I'm working on at the moment. Once this information has been finalized it'll be able to compile an awp project or single files. It will read information from .opts files, and if they're not available it will scan files to find words like "window", "dialog", "writeln", etc to try and determine whether or not you want a windows or console compile. And all the output will be piped from the utilities using the Pipe class I'm going to write.

Those will be part of the utilities included with the common class library.

[Ionic Wind Support Team]

? Of course the IDE is a real one.  Integrated development environment.

Both IDE's were written fromt he ground up by myself.  I used a few third party MFC classes for things like the tabbed windows, and docking displays, but other than that it is all from scratch.

IBasic's editor was of my own design.  Scintilla wasn't around when the original IDE was wriiten. 

[Shannara]

? Of course the IDE is a real one.  Integrated development environment.

Both IDE's were written fromt he ground up by myself.  I used a few third party MFC classes for things like the tabbed windows, and docking displays, but other than that it is all from scratch.

IBasic's editor was of my own design.  Scintilla wasn't around when the original IDE was wriiten. 

My apologies. I did not mean to offend. I was only a bit miffed when I signed up for IB and found out that , that "IDE" wasnt one. But after our posts and replies, was determined that it was a bolt on. No offense intended. But I was just wondering if Aurora was following the same way or it would be bonafide IDE You eased my worries!

[Parker]

I'm not getting this. I was under the impression that an IDE was a program that you can at minimum, edit your source code and compile it without having to switch to different tools, like notepad / command prompt. So the IBasic IDE is an IDE, so is Aurora's. But keep in mind that Aurora's IDE will keep getting enhancements as we progress, especially as the compiler becomes more complete.

Maybe what you meant is IBasic's IDE doesn't have a full form designer like VisIBasic where the window design and code editing are combined. But it's still an IDE.

[Rock Ridge Farm (Larry)]

That would be a 'RAD' component. The best one of these I ever saw was
Clarion.

[Shannara]

I'm not getting this. I was under the impression that an IDE was a program that you can at minimum, edit your source code and compile it without having to switch to different tools, like notepad / command prompt. So the IBasic IDE is an IDE, so is Aurora's. But keep in mind that Aurora's IDE will keep getting enhancements as we progress, especially as the compiler becomes more complete.

Maybe what you meant is IBasic's IDE doesn't have a full form designer like VisIBasic where the window design and code editing are combined. But it's still an IDE.

An IDE, by definition is an Integrated Developer (/ment) Environment.Thus, if you edit a dialog/form/window, the changes would show in the code section. The same with if you did changes in the code, the changes would show up in the dialog designer. Integrated, means with-out the need to patch/bolt on ... copy things from back and forth, just for them to be in sync. When you have to constantly generate code needed for the code editor, or visa versa, then I do not think that's integrated at all, but a bolt on or could even be considered seperate tools.

Thus my question Of course, thats my opinion, but im going off the definition for that acryonim (sp? I cant spell today). The iBasic tool set is closely coupled, but I did not see it as integrated because of the extra steps involved to sync the tools together. With Integration there would be no steps at all to sync the two (dialog editor, code editor), would be automatic.

I havent checked out Clarion, but I know the visual studio product is an IDE.

Just again, this is IMO, not meant to offend.

Please note, this does not prevent me from using Aurora, heck, I already bought a copy. I just wanted to know if I would need to do some extra steps to keep both in sync with each other ... (Ironic using my nick .. )

[Parker]

Hmm, I see. I never considered that as a necessary part of an IDE, but I think that's enough said on the subject. We're still in the alpha, and Aurora has the same dialog editor as IBPro did. After all, it's just a dialog editor like Visual C++'s. Visual Studio also has a .NET form designer, but their and Aurora's dialog editors aren't meant for that purpose. But I'm sure someone will write one eventually. I've been thinking about different ways to accomplish it, and after the windows API headers are translated I may try it.

[Shannara]

My apologies for getting off subject and hijacking the thread. It truely wasnt my intent. But anyways, even since the eidtor works the same as iBasic, I find it quite usefull

[Zen]

What about still keeping the old IDE? For people like me who had no knowledge of programming at all, i found it good because it wasnt like someone sitting you in a cockpit of a fighter jet and saying make sure you push the right button kid. If IBasic was like C++ or the VisualStudio IDE i think i wouldnt even of bought it. Obviously now i am more experienced and i am at a stage where i think i could cope with a more complex interface with tons of options.

...Still dont fancy the cockpit though

Lewis

[Ionic Wind Support Team]

Sync,
Actually I misunderstood you.  My idea of an IDE is the same as Parkers, and Microsofts.  However there will be more integration and many more IDE enhancments as get closer to the release version.

I started programming when the command line tools were not integrated with an editor.  You coded in a text editor, started a shell and manually typed in the commands to compile, assemble and link.  Or used a batch file if the compiling steps didn't change often.  Tools like 'make' came about because of the lack of integration.

Paul.

[Zen]

Paul. Back with IBasic you made a post about version 2 and features you intended to add. Do you plan on making some of those things for Aurora? Such as...

Planned IDE changes:
-Integrated utilities for resources. Including an icon editor.
-Built in project wizards to create skeleton code for various tasks.
-Compatibility with third party "make" tools. Importing of make files already done.
-Complete separation of the compiler proper fron the IDE. My own make file format is based on NMAKE. The IDE just generates the make file and calls the compiler proper.
-With the above changes you can include code for other compilers to be included with the build. So direct adding of C, C++ ,etc. files to the project will be possible.
-Adding separate ASM files to project already functional.
-More resource types supported including version information.

Just wondering what plans you have

Lewis

[Parker]

I personally liked the idea of Paul's make, so we know what's going on instead of having to guess at it. I wonder how hard it is to hook CreateProcess

My apologies for getting off subject and hijacking the thread.

I don't mind. What I meant is that I was done talking about that. It's not my decision what's said and what isn't in these forums. Besides, the discussion seems to be wrapping back around anyways

[Zen]

I think what i would like the most is also the MAKE part. Like you said its good to have a little more control over you compile process. Also a better resource editor and the ability to add / modify more resource types such as dialogs, string tables etc.

Lewis

[seberbach]

Paul wrote a  "menu editor" for IBasic which was dedicated to building/editing menus.  It seemed to me a good idea to have a template for building "editors" for any kind of control or interface element whenever somebody wants it. Having the source code for such a template seems more useful an enabler than just having a one-app-does-all form designer/Guibuilder, etc, etc. which you have to wait months to see your particular needed feature added, if ever.

This menu application was very instructive to me because it was possible to "take it in" without drowning in complexity, and even start thinking of ways to improve it further someday. It is like a tutorial which once you go through "building" it like a hobby kit, you can " keep" it as a useful part of your development toolset.

I would enjoy seeing more such modular/tutorial  control-editing applications which are dedicated each to a specificl type of interface component.

If Paul translated his IBasic menu editor example to Aurora, we all could read between the lines, where and how the philosophy of Aurora is intended to apply by its author.  It seems to me that Object based language architecture is conducive to design consensus, collaboration, and even simplification. (particularly when extensible so initial designs do not need all features for all people at the start, and best of all if useful template examples do not go too far into fancy jargon and syntax way over my head, like some eye-roller corporate-designed stuff I've seen but could never understand without hours/days/weeks/years of prerequisite study.)

That way, in the future, new components could become editable without having to rebuild the entire original IDE. Even your own components, such as audio filters, charts,  or other specialty widgets could follow the template closely enough that other people would understand and use them more easily.

And meanwhile, the more basic, or common modules could be developed in parallel, and publicly available sooner, yet later become more integrated once the language design is completed and stable.

Steve