Issue 65367 - OOC680_m0: external is not tagged
Summary: OOC680_m0: external is not tagged
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: solenv (show other issues)
Version: current
Hardware: All All
: P1 (highest) Trivial (vote)
Target Milestone: OOo 2.0.3
Assignee: rt
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-14 23:37 UTC by quetschke
Modified: 2006-05-19 10:20 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description quetschke 2006-05-14 23:37:09 UTC 
Please ignore/close if you already know this:

external is not tagged for OOC680_m0, build.pl knows this immediately:

build -- version: 1.148

Fetching dependencies for module external from solver... failed...
Fetching from CVS...  failed

but the build needs until connectivity/source/drivers/ado to realize that
ado/ADOCTINT.H is missing.

I know, a toplevel dmake would have caught this immediately, but ... ;)
Comment 1 pavel 2006-05-15 07:25:06 UTC 
Can we solve these external problems for now and for the future too? What is the
technical reason for them?
Comment 2 rt 2006-05-15 08:46:02 UTC 
Fixed; external is tagged now.

pjanik: the problems arise from the fact that we have an OOo modul 'external'
and an Hamburg internal 'external'. Both have the same name due to a history
misconception. We would like to remove one of them (or both), but progress here
is very slow :-(
Comment 3 quetschke 2006-05-16 05:16:02 UTC 
Sorry, but d.lst is not tagged correctly, see:
<http://tools.openoffice.org/source/browse/util/external/prj/d.lst>.
Comment 4 rt 2006-05-16 09:44:39 UTC 
Sorry :-(

BTW, there is a CWS in progress (ause036) which will remove Hamburgs internal
'external' (unfortunately it's an internal issue which you cannot see in EIS).
When this has been done the OOo modul 'external' will be covered by all normal
processes and therefore be  less errorprone.
Comment 5 rt 2006-05-19 10:20:12 UTC 
closing.