Re: How to make unokywds.hxx from module sd usable for svdlayer.cxx in module svx?

On 18/09/2018 18:39, Regina Henschel wrote:
> Stephan Bergmann schrieb am 18-Sep-18 um 16:53:
> > On 18/09/2018 16:21, Regina Henschel wrote:
> > > The file unokywds.hxx containes a lot of string definitions. My case
> > > is about sUNO_LayerName_controls, which is "controls".
> > >
> > > The ctor of LayerAdmin in svdlayer.cxx has the wrong text "Controls"
> > > instead of "controls". I have now simple set the correct text to
> > > verify that is solved the problems. But I would like to use
> > > sUNO_LayerName_controls to avoid such error in the future.
> > >
> > > How to do that?
> >
> > By moving sd/source/ui/inc/unokywds.hxx to a suitable include/ sub-dir,
> > presumably include/svx/ if that's the lowest module that would use it
>
> What do you mean by "lowest"?

One that is on the bottom of the module dependency graph induced by the 
dependencies of executables and libraries from one module on libraries 
from other modules (i.e., what `make dump-deps-png` would show if it 
would still work).  (Include-file--only dependencies are not taken into 
account there, so it would in theory be fine if a .cxx from lower-layer 
svx included unokywds.hxx from a hypothetical higher-layer include/sd/ 
to use those local-linkage sUNO_* variables.  In practice, such "reverse 
dependencies" probably just cause human confusion and should be avoided.)

> > (and probably renaming the file, to reflect that it contains sd-specific
> > strings; and adapting the file's INCLUDED_... macro to reflect its new
> > place/name).  Remember to adapt solenv/clang-format/blacklist when
> > moving a file listed there.
> >
> > (unokywds.hxx only contains static const variables, so including it from
> > somewhere else than Library_sd should be fine.)

(strictly speaking, the variables are not static, but have local linkage)

> Oh, that is a larger change. I suspect it is better done separate from 
> my current changes from localized to real layer names.

I guess both approaches would be acceptable.  While it may technically 
be a somewhat larger change (so could warrant a commit of its own), it 
is a rather trivial change after all, so combining it into a single 
commit together with its new use in svx would nicely demonstrate /why/ 
the change was made.