On 10/21/2012 1:31 PM, andy pugh wrote: > On 21 October 2012 17:01, Charles Steinkuehler <[email protected]> > wrote: > >> #include "hal/components/thermistors.h" >> >> ...which seems kind of odd, since the comp file resides in >> hal/components along with the thermistors.h file. > The issue here is that the c-code which is generated from the .comp > file is _not_ kept in the same place as the .comp file.
Well, when I directly invoke "comp" on a file in the working directory, it leaves the resulting .c file in the same working directory. I suspect the problem lies in the way comp is invoked in our Makefile. Considering your original problem statement, the files of interest are, relative to the directory into which I untarred the source dist, src/hal/drivers/mesa_7i65.comp src/hal/drivers/mesa-hostmot2/hostmot2.h In my not so humble opinion, one ought to be able simply to say before the ;; delimiter in the mesa_7i65.comp file include "mesa-hostmot2/hostmot2.h" or more verbosely (and essentially that all files are relative to the directory into which the source distribution was untarred) include "../../hal/drivers/hostmot2/hostmot2.h" To do otherwise is to require people coding .comp files to know too much about what goes on behind the curtain. > To further complicate matters it seems to end up in a different place > when it is compiled with "make" than when it is compiled with "comp" Agreed, but the person creating a .comp file shouldn't have to know about this (which is what you were getting at in your original post). > >> So...is there a reliable or recommended way of including *.h files in >> *.comp components, > There is an "include" command that can be used before the ;; delimiter > in the comp file. You can also use a #include in the C-code after the > ;;, but it tends to be too far into the code to include types (if, for > example, you want variables in the "variable" section which are not > built-in types). The comp "include" command puts a #include near the > top of the generated C file. > > However, the "include" command is undocumented, probably because of > the problems you are seeing. The place to fix all this is probably in > the comp.py program, as that probably knows where it is putting the > C-code, and ought to be able to repair the path. > Considering the quick-n-dirty test I just did with mesa_7i65.comp, a comp "include" command before the ;; delimiter appears simply to be quoted into the resulting .c file with an appropriate leading "#" prepended to it. Not very mysterious and consistent with what I said above about how I thought the include statement should be expressed. The gcc preprocessor behavior* with #include is straightforward and would deal with this correctly if gcc is invoked in the working directory. As I said before, I'll have to do some more digging around, but it's an interesting little problem. Regards, Kent *the stated rules for #include "file" and #include <file> are simple but include a kicker (system directories and directories included via the -I directive can end up being searched in either case) and get complicated because of possible compiler directives. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
