I've yet to see anyone suggest a structure that could not be handled in simple .ini files. (Even yours f0dder... I can and did get all your same info into an .ini) SO..... Let's start again slowly. Who is going to use FILES? Raise your hands. Now start adding the attributes you think should be included for a file. I'll go first.
In my implimentation, I'm fully expecting to re-built the whole .ini each time it's saved. Clean wipe, then start fresh. I'll probably add some key feature to know when I'm opening a 'forign' file, and offer option to make a backup.
The key would probably be an section, but that's for way later.
(All must have this and use in the same way)
1) File path and name (1 string)
(free to use or ignore any of these)
4) LastChangeDate (sure it's the filedate. Why should I have to check the file itself?)
Now, who's next?
There is the concept of Workspace, and Project that needs to be concidered. We could have an INI for each Project and then one for the Workspace; or we could just have one big Workspace file? I favor the former as I hope to allow the creation of very large projects, and I think that these files will be easier to maintain that way. Then the IDE could load individual Projects, or a whole Workspace of Projects - or quite possibly some IDEs will only function at the Project level. + = Optional Files a. Name b. Author+ c. Version+ d. Comments+ e. Creation Date+ f. Last Modified+ Projects a. Name+ (defaults to file INI name) b. Version+ c. Comments+ d. Output file (only one allowed) e. List of input files Workspaces a. Name+ (defaults to file INI name) b. Version+ c. Comments+ d. List of Projects (build order) Don't we need some kind of build instructions at the file/project level? :P bitRAKE. This message was edited by bitRAKE, on 2/28/2001 2:26:06 AM
I agree with ernie on the whole INI thing. I have yet to see one good reason why an INI file can't get the job done with ease and efficiency. The fields ernie listed are great, but i think different build configurations are in great need. Something like this: (If an IDE didn't want to use multiple configs, it could use the default.) Active=Release Config1=Release Config2=Debug Config3=Win32Whatever <---- simple non-multi config apps could use this Assemble=masm /t test.asm Link=link SUBSYSTEM:WINDOWS test.obj Assemble=blah Link=blah Assemble=blah /zd /zi Link=blah Assemble=whatever Link=yougetthepoint What do you guys think of that, allowing multiconfigs, but if an app chose not to, it could read the default config, the default config could be the same as the release.... it doesn't really matter.
I'm well aware that "the stuff I need" can also be done using INI files. But I can't think of a way to do it that also *looks* nice. The problem with INI files is that we have all these sections, but a section can be *anything*. The idea of my structured approach is that it's very easy to see what is going on, the format is practically self commenting, and easy enough that you don't actually need the IDE to set up a project (though that is what you are going to do 99% of the time). I believe there is a point where the INI file approach would be hard to hand-edit, when you have enough files and build rules (something that I often have - and not without reason). Also, INI files could lead to namespace clashes, which is not a good thing.
I would recommend looking at who your target audience is, first. Are you trying to make it easier for the IDE developer or for the IDE user? How many times does the IDE user need to change IDE settings outside the IDE environment? If you can answer these questions, then it should be easier to make a descision of using INI files instead of XML. For the IDE user, I would think that INI files are easier. But, shouldn't the IDE provide a good functionality to change these settings from within the IDE? Why does one want to use an IDE in the first place? The IDE should not limit the user. I think we can agree on that. For the IDE developer, I would say that INI files offer an easier implementation then XML. XML would require as a minimum an XML parser. Are you going to ship your parser or built your own? You may or may not need a DTD file that includes your rules. Are the additional overhead and development time really worth it? You will need to keep track of XML standards and changes to be up-to-date (if you are building your own parser.) Here is a crazy thought: Instead of using XML for settings, use XML to wrap your assembly code. Or for that matter, wraping any programming code in XML should provide a big benefit of portability. :)
I think .ini files are good enough. If there will be an outstanding IDE (a one almost everyone uses)it`s writer has decided how it should be done (like Microsoft with their Windows OS) not always the best way but the most used will rule .I`m still waiting for a good IDE to come. (Iczelion PLEASE write one).
re: John Richardson's ini file format .. hmmm, looks almost identical to VisualASM's .vap format :P~
compile="C:\VisualASM\bin\ML.EXE /c /coff /IC:\VisualASM\inc visasm.asm"
build="C:\VisualASM\bin\LINK.EXE /RELEASE /SUBSYSTEM:WINDOWS /VERSION:4.0 /MAP /LIBPATH:C:\VisualASM\lib\ visasm.obj res\va.obj"
compile=C:\VisualASM\bin\ML.EXE /c /coff /IC:\VisualASM\inc visasm.asm
build=C:\VisualASM\bin\LINK.EXE /RELEASE /SUBSYSTEM:WINDOWS /VERSION:4.0 /MAP /LIBPATH:C:\VisualASM\lib\ visasm.obj res\va.obj
where holds current active/default
then file usage stored as follows :
1=Main ASM Files
14=Dialog ASM Files
then a "setup" section ..
so much one can do with a simple .ini ;
To Clive(entro-p): Yes, it's almost identical to your visasms format, with a few exceptions. But that's because i like it:)