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

James Diffendaffer jdiffendaffer at yahoo.com
Wed Jan 24 23:15:36 EST 2007


I should point out that my suggestion can be implemented with a
preprocessor.  That means it could be made to work with *any*
assembler without modifying the assemblers.

--- In ColorComputer at yahoogroups.com, "James Diffendaffer"
<jdiffendaffer at ...> wrote:
>
> 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.





More information about the Coco mailing list