[Coco] [Color Computer] Re: CCASM winclude/wincludebin

[James Diffendaffer]

The idea of including over the web is ok, I just don't like the way
you intend to implement it.

If you want to do this there's (IMHO) a better way that is more suited
to how people actually develop.

People develop against a fixed version of libraries.  When that is
working then they may try to integrate with other versions of
libraries they are using.  If someone breaks something they need to be
able to go back to the old library without a lot of hassle.  
People may even need their code to work with multiple versions of a
library and may periodically need to test against them all.

So, instead of winclude the way you are thinking you could support
aliases for paths which could be on the local drive or on the net,
whatever you prefer.  Then just allow you to define configuration
files with the aliases as part of the project or IDE environment.
Most compilers have you define an include: path in your environment
and this would be similar but only set within the IDE.

A possible example: 
include <$music_path$/music.i>
include <$font_path$/alienfont.i>

Then you could define the path for music or fonts to be local or
remote just by selecting a different config file or by modifying the
config file.  It would make it fast and easy to built against multiple
 libraries with different remote/local paths.

The way you suggest would require changing all the includes in all
files where this would allow you to change things globally very easily
and the changes could be used for multiple projects without much
difficulty.   Sure, you could have an include file for each setup with
the proper paths but you have to change that manually.  If it's done
from the IDE it's less fuss.

It would allow you to do the same thing but in a manner more suited to
the task.  I've actually done something similar before but it was
through environment variables and batch files.  We just ran the batch
file to set the environment to point to the proper version we wanted
to build/test against.


---original message--------------------------------
At 02:42 PM 1/23/2007, you wrote:

>I'd never use winclude. The net could be down, some people may have

>dialup (like me at the moment), changes to the libs could break

>people's code, updates could introduce bugs... bad idea IMHO.



In my opinion as well, it's too simple to go too wrong. :)

Most of the source files won't change, and additional versions could
be added. No problem. This is also just a CoCo/Dragon/Vectrex, etc.
feature since the feature is within CCASM, not really the IDE itself.

Perhaps the winclude functions will be more used by teams working on
the same project, where the author of certain components would host
their files for the others to include. There's lot of uses.

By the way, while I'm on the subject of assemblers, Rainbow 2.0 and
probably the last 1.x update will let you add your own cross
assemblers and configure them from within the IDE.

Rainbow 2.0 works much better and I've added probably 10 assemblers
just by copying and pasting the assembler's root folder (a folder
containing the .exe and all support files and subdirectories) to the
c:\Program Files\Rainbow IDE\Assemblers\ folder. It was easy adding
the ASxx series assemblers, but TASM (a multiple CPU cross assembler)
required more support in the IDE.