Well, I guess the recompilation tradeoff is worth the temporary annoyance of
adding the specific debug flag header file everywhere.

I'm also hoping that the new changes will allow us to eventually make
compound flags of compound flags.

On Thu, Jun 9, 2011 at 12:42 AM, nathan binkert <n...@binkert.org> wrote:

> Oh, and I forgot.  Compound flags generate a header file as well.
> debug/O3CPUAll.hh for example would have all of the flags that
> O3CPUAll covers
>
> On Wed, Jun 8, 2011 at 9:40 PM, nathan binkert <n...@binkert.org> wrote:
> >> What do people (mostly Nate) think about having a single header file for
> all
> >> debug flags?
> >>
> >> Instead of "#include "debug/MyFlag.hh" for every flag you want in a
> DPRINTF,
> >> you could say "#include "debug/debugflags.hh" and that would cover all
> the
> >> debug flags available for DPRINTF.
> >>
> >> Would that (the old way?) not be more desirable then the new way of
> >> including debug flags? Are there infrastructure things that make this
> >> complicated?
> >
> > The whole reason I changed the flags around was to avoid the
> > centralized file :)  The main problem with the centralized file is
> > that if you add or remove a flag, you have to recompile just about
> > everything.  There is no reason that you couldn't do localized
> > includes for a set of flags though.  For example, you could add a file
> > to the src/cpu/inorder directory called debugflags and include the few
> > debug flags that you want and that way only the inorder CPU would be
> > rebuilt if you added a flag to it.  Adding the centralized file back
> > wouldn't be quite as bad as it was before since it would only be a
> > centralized .hh file and not a centralized .cc file (which makes doing
> > things like adding a flag for a unit test a real problem.)  I'm pretty
> > sure it's not worth it though and the localized files that include a
> > bunch of flags for each CPU model are probably as much as anyone
> > really needs.
> >
> >  Nate
> >
> _______________________________________________
> gem5-dev mailing list
> gem5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>



-- 
- Korey
_______________________________________________
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to