> >So you created a separate BAT file for each buildable
> >source module in the SOURCE directory?
>
> Correct. That seemed to be the way you had done it on the environment I
> originally received from you, and each build file then has only the
> appropriate source names for that project.

Actually you did it per resulting executable, not per module.  The
comments in your last post implied it was per module, but that was
probably because they weren't updated after a cut and paste.

> I also did another modification
> to the individual build files so that the linker file gets the file
names
> automatically entered into it.
>
> copya -out hkp.libpic -s "/c"
> copya -out hkp.libpic -append -s hkp.lib
> copya -out hkp.libpic -append -in hkp.mlist
> libpic hkp.libpic
>
> copya (cog)source/pic/p16f876i.linkpic hkp.lkr
> copya -out hkp.lkr -append -s "LIBPATH ."
> copya -out hkp.lkr -append -s "FILES hkp_strt.o"
> copya -out hkp.lkr -append -s "FILES hkp.lib"
> linkpic hkp

This looks like it was modified from a rather old version.  This may have
been before the SRC_LIBPIC and SRC_EXPIC scripts existed.  The new version
of BUILD_HAL_EXPIC.BAT looks like this:

  ...
  call src_aspic pics hal_s22
  call src_aspic pics hal_s35

  call src_aspic pics hal_strt

  call src_libpic pics hal
  call src_expic pics hal

> note the line "del hkp.mlist". I then modified src_aspic.bat to build
this
> file like so, so that it rebuilds hkp.mlist with the names of the files
that
> need to be linked, without having to maintain multiple files when
another
> module was added to the project.

Very nice.  I've been meaning to do something like that.  I would do the
delete like this:

  if exist hkp.mlist del hkp.mlist

because otherwise it would not run the first time or after the SRC
directory got cleaned out.  I was also thinking of checking for the
existance of the MLIST file in the SOURCE directory and appending its
contents to the automatically created list.  This leaves a way to
explicitly specify additional modules to add to the library, although I've
never needed to do that so far.  The only other problem I would have with
your method is that the automatic MLIST file is named from the source
directory, not the resulting buildable.  I guess it wouldn't be a problem
unless you were doing concurrent builds.

> However it sounds like you have modified the batch files quite
> a bit since I originally obtained these from your site, so my
> modifications may not map straight into your current methodology.
> I will have to look at the new files to see.

Yes, things have changed a little.  I really don't like the BAT file
method at all, although it's kind of "good enough" now.  The BAT files are
a stopgap between the old source code control and build system dying
because it only ran on ancient museum piece computers, and the new system
I am working on.  The heart of the new system is an intelligent command
line interpreter that is vastly superior to CMD.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu