Re: [dev] OOo w/o URE

2007-04-17 Thread Stephan Bergmann

Stephan Bergmann wrote:

FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32


See 
http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE 
for work on this.


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [dev] OOo w/o URE

2007-04-17 Thread Caolan McNamara
On Tue, 2007-04-17 at 10:50 +0200, Stephan Bergmann wrote:
 Stephan Bergmann wrote:
  FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32
 
 See 
 http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE
  
 for work on this.

That's most excellent, I like the .rdb split, that's where I got stalled
when I made a stab at this for last years OOoCon.

C.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[dev] Brukerveiledning til Writer og Calc

2007-04-17 Thread Marna Brit Fossen
Hei !!
 
Jeg forsøker å laste ned PDF-utgaven av brukerveiledning fra nettet men får den 
ikke opp...
Kan dere sende til meg på mail ??

Haster da jeg skal ha opplæring imorgen.
 
Marna Brit Fossen
Notabene
Tlf: 32 21 35 45
Fax: 32 21 35 42
 


[dev] How to include inter-module headers

2007-04-17 Thread Stephan Bergmann

Hi all,

http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fhedaburemove01 
delivered us from hedabu.


However, the way this was done lead to the module-local inc/$PRJNAME 
(where PRJNAME is the module name) to be added to the C/C++ compiler 
include search path in every module (solenv/inc/target.mk:1.194).


That triggered http://www.openoffice.org/issues/show_bug.cgi?id=76340, 
where obscure constellations in sal prohibit adding sal/inc/sal to the 
C/C++ compiler include search path in sal.  The ad-hoc fix was to not 
add inc/$PRJNAME if $PRJNAME == sal (solenv/inc/target.mk:1.195).


That in turn caused Ause and me to reflect on the overall fidelity of 
generally adding the module-local inc/$PRJNAME to the C/C++ compiler 
include search path.  What is the state the code should ideally be in?


A  Should inter-module includes generally be module/header instead of 
just header?  Then the current hedaburemove01 changes would be a 
pragmatic hack---instead of changing tons of include lines in tons of 
source files, change a single line that magically extends the search 
path wherever necessary (and also where not necessary).  If this is the 
ideal state, the drawback of the hedaburemove01 changes is that they 
potentially move us further away from that state---new code can 
introduce sloppy includes of just header that should be 
module/header, even in modules where this would have been caught before.


B  Or should inter-module includes generally be just header instead of 
module/header?  Then the current hedaburemove01 changes would be sound 
(and the modules that until now only allowed module/header should 
ideally be cleaned up).


C  Or should we allow inter-module includes to be just header and 
module/header higgledy-piggledy?


In my opinion A should be the ideal state to aim for:  It makes more 
information explicit than B, so it should be more helpful to code 
readers, and it should be less error prone (witness issue 76340).


Others?

-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]