[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