>
> Good thinking.
>
> If this part is touched, I have another wish:
>
> Command line switch -di[.ch file name].
>
> Right now we can only issue -d__SOMEDEFINE__ but cannot
> supply a .ch file containing as many defines we wish.
> At times I feel a limitation of it, right now much more than ever.


I'm not sure I understand what you mean.
You can have the same effect either by using -u
option, or simply -D_SOMEDEFINE_
and #ifdef _SOMEDEFINE_ / #include "this.ch" / #include "that.ch" / #endif

Actually, even my suggestion could be done differently,
and maybe it'd be a better solution (I kept thinking about
this after sending the mail ;), to cover the case I've cited,
the app needs some kind of library to complement the
header. The latter definitely needs help from the make
tool. So, I'd feel it simpler to move the header logic also
to the make tool level, and use such #define to communicate
package presence.

This starts to be a bit 'configure' like functionality, and could
use a system which defines packages. I'll think about it further.
It can get quite complicated if we want to automatize dependencies...

In the shade of these, my initial idea is pretty broken :)

Maybe something like this:

hbgtwvg.hbp
---
uses=hbwin xhb
prgflags=-DHAVE_GTWVG
libs=gtwvg
libpaths=C:\libs
autodetect=yes
---

'autodetect' would lookup all 'libs' on 'libpaths' (plus normal libpaths),
would then do the same with 'uses' .hbp files, and if self and
dependent libs are available, it would add -DHAVE_GTWVG to
the command line.

Just quick thoughts.

But to acheive this functionality I have to include a .ch file
> in every prg in my project, a hell of the job.
>
> May be I am missing something about command line switches...


This seems -u, but even better (without side-effects) is to use
a central header and add the new one to just that one file, problem
solved forever. I use such central header for all my libs and apps.

Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to