Mail Archives: djgpp/1998/10/19/17:49:35
Robert Hoehne wrote:
> > For Robert :
> > Aint' time has came to implement profiles in rhide ?
> > i.e. different set of options/sources for different targets.
> > Or i'm missing something?
>
> Do you have any hints what options should be en-/disabled
> for such targets? Let say the following:
>
> - fastest code
> - smallest code
> - developing code
> - releasing code
There are several things to implement to be able to build
code with several option's set ...
One is "profile". I.e. you define a set of profiles (customizable by
users), set options and when building can select profile to use.
It will help to keep several favorite sets of options, commonly
used by the user.
Another thing is "multitarget", when one can make several targets
in one project, assign profiles to targets or even change file-set.
For example, in my DLM project there are two main targets -
manager and stub. And walking between dirs to customize other
target is not so pleasant. Multitargets usually shares some include
files, so the preferrable structure of targets is
/project_root_dir
rhide.gpr
here may reside common files for all targets.
/target1.dir
here may reside target's profiles, gpr files and other stuff,
specific for the target
/target2.dir
/common_include
Just got a crazy idea. Why not to make subprofiles override
only part of the parent profile ? Then, if some target requires
special options to be built, it can override them, leaving
other options customizable for the whole project. That's just
an idea ;)) Idea's are endless - there are always way to
make even better ;)
P.S. I know, that rhide can manage gpr files as dependecies,
but it is difficult to manage them. If they were expandable,
like trees ....
============================
Ilya P. Ryzhenkov aka Orangy
E-mail : orangy AT inetlab DOT com
ICQ : 17942172
- Raw text -