Issue 13533 - configure does not set COMPATH correctly the first time
Summary: configure does not set COMPATH correctly the first time
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: code (show other issues)
Version: OOo 1.0.3
Hardware: All All
: P4 Trivial (vote)
Target Milestone: OOo 1.1.2
Assignee: quetschke
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-17 03:38 UTC by Unknown
Modified: 2004-10-26 00:44 UTC (History)
3 users (show)

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


Attachments
patch for configure.in (444 bytes, patch)
2003-04-17 03:42 UTC, Unknown
no flags Details | Diff
Patch for configure (330 bytes, patch)
2003-04-17 03:43 UTC, Unknown
no flags Details | Diff
patch for configure.in (1.1 beta 2) (504 bytes, patch)
2003-06-06 03:09 UTC, Unknown
no flags Details | Diff
patch for configure.in for OOO_STABLE_1 (504 bytes, patch)
2003-06-06 03:16 UTC, Unknown
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2003-04-17 03:38:24 UTC
When running configure on a fresh build, with no config.cache file in the
config_office directory, it will set the COMPATH variable in my Blay.Set file to:

/usr/local/gcc-2.95.3/bin,

and in my PATH env variable it is:

/usr/local/gcc-2.95.3/bin/bin

Running configure a second time, you wont see this problem, because if COMPATH
is cached, it used that, and strips the last directory off, so it becomes

/usr/local/gcc-2.95.3,

and is subsequently set to:

/usr/local/gcc-2.95.3/bin in PATH!

This is because COMPATH is initially set to:

/usr/local/gcc-2.95.3/bin/gcc, and the last part is stripped out via the
following sed expression. (so /gcc will be stripped out)

COMPATH=`echo $COMPATH | $SED "s@/[^/:]*\\\$@@"`;

This should be changed to strip $CC out of the path (if it is there), as well as
the level before it to!

COMPATH=`echo $COMPATH | $SED "s@/[^/:]*[/$CC]*\\\$@@"`;

With this change, configure will generate the correct COMPATH everytime!
Comment 1 Unknown 2003-04-17 03:42:09 UTC
Created attachment 5714 [details]
patch for configure.in
Comment 2 Unknown 2003-04-17 03:43:03 UTC
Created attachment 5715 [details]
Patch for configure
Comment 3 Unknown 2003-04-17 07:46:30 UTC
added keyword and target milestone
Comment 4 Unknown 2003-04-17 08:18:44 UTC
re assigning to Ken F
Comment 5 quetschke 2003-04-19 10:17:59 UTC
This is already fixed in HEAD/cws_srx644_ooo20030412. That should be
backported. See thread around
<http://porting.openoffice.org/servlets/ReadMsg?msgId=651324&listName=dev>

But as I mentioned in that thread some extra care has to be taken for
COMPATH.
Comment 6 Unknown 2003-05-08 01:08:33 UTC
OK, I will have a look at that Volker and give it a try.

Thanks

George
Comment 7 Unknown 2003-06-06 03:08:04 UTC
I still see the same problem with 1.1 beta 2!

I will attach a patch that basically strips "/bin" off the end of
COMPATH (only if COMPATH ends with /bin though - obviously)

I think the patch should be ok, as configure (or set_soenv) will add a
/bin to the end of COMPATH anyhow, when it is generating the PATH env
variable!

Here is a new patch for 1.1 beta 2
Comment 8 Unknown 2003-06-06 03:09:13 UTC
Created attachment 6692 [details]
patch for configure.in (1.1 beta 2)
Comment 9 Unknown 2003-06-06 03:15:38 UTC
Now adding re-worked patch for OOO_STABLE_1
Comment 10 Unknown 2003-06-06 03:16:12 UTC
Created attachment 6693 [details]
patch for configure.in for OOO_STABLE_1
Comment 11 quetschke 2003-06-06 09:07:46 UTC
Hi Goerge,

your patch is *not* approved, have a look at the following link why:
<http://porting.openoffice.org/servlets/ReadMsg?msgId=651384&listName=dev>

If you know it works for you enclose your changes with an "if IRIX"
condition, but I'm pretty sure it might break W32 builds.

I know this part of configure should be reworked, but I have ZERO time
right now.

Volker
Comment 12 khendricks 2003-06-06 13:46:52 UTC
Hi George, 
 
It seems this change is a bit controversial and might break other ports as Volker 
already pointed out. 
 
If there is no easy solution right now, why now do as Volker suggested and make 
sure your change only happens for Irix with some type of ifdef to protect it. 
 
Then I am sure we can approve it to get your build in and we can work toghether 
after 1.1 to figure out a way that works for everyone (if that even exists). 
 
Hope this helps, 
 
Kevin 
 
Comment 13 Unknown 2003-06-16 05:19:43 UTC
re-assigning to Nick Blievers, as I am finishing my work on the Irix
port. He will continue on from here, and he may wish to Re- assign
this back to Ken F
Comment 14 nickb 2003-07-07 02:35:59 UTC
Accepting...
Comment 15 utomo99 2003-10-31 04:09:23 UTC
Hello, 

I found that this Issue is targetted to 1.0.4. 
Is this already solved in 1.1 ? if not Can you please retargetting
this issue since 1.0.4 is not planned. maybe to 1.1.1 ? 

Thanks
Comment 16 nickb 2003-10-31 04:39:05 UTC
Changed target
Comment 17 pavel 2003-11-25 22:00:00 UTC
Nick, what is the status of this change?
Comment 18 nickb 2003-11-25 23:33:06 UTC
I haven't had a chance to revisit this, but I believe it will still be
a problem. Its not exactly a major problem tho, so am changing to p4
Comment 19 pavel 2004-01-09 09:38:17 UTC
Retarget to 1.1.2. If you want it to be 1.1.1, please change it back with update
patch for fix2.
Comment 20 Martin Hollmichel 2004-04-28 06:51:47 UTC
set this P4 to Ooo 2.0 target, can please anybody verify, if the patch make it
already into 680 successfully ?
Comment 21 quetschke 2004-04-28 14:52:24 UTC
I'll take care.
Comment 22 quetschke 2004-05-19 21:17:31 UTC
I just checked config_office/ from cws_srx645_ooo112fix2 and
cws_src680_ooo20040509. For all compilers except MSC $COMPATH is used as
the path to the compiler executable and it is used without adding /bin
when creating the new $PATH.

Someone fixed it in the meantime, resolving as fixed.
Comment 23 quetschke 2004-06-02 15:53:30 UTC
The comment before qualifies as verified.
Comment 24 Martin Hollmichel 2004-10-26 00:44:59 UTC
close issue.