Summary: | ASTERISK-10384: menuselect fails to resolve dependencies | ||
Reporter: | Tzafrir Cohen (tzafrir) | Labels: | |
Date Opened: | 2007-09-25 00:32:16 | Date Closed: | 2007-09-25 02:38:51 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/BuildSystem |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | ## Expected: ############## ./configure make # dang! I really don't want FEATUREXYZ support ./configure --without-xyz make ## In practice: ################# make # dang! I really don't want FEATUREXYZ support ./configure --without-xyz make Results in: menuselect/menuselect --check-deps menuselect.makeopts *********************************************************** The existing menuselect.makeopts file did not specify that 'chan_h323' should not be included. However, either some dependencies for this module were not found or a conflict exists. Either run 'make menuselect' or remove the existing menuselect.makeopts file to resolve this issue. *********************************************************** make: *** [menuselect.makeopts] Error 255 If menuselect is smart enough to resolve dependencies, it should be able to fix them without bothering me. | ||
Comments: | By: Russell Bryant (russell) 2007-09-25 02:38:49 I do not consider this a bug. What you are demonstrating here is a situation where there is an existing "menuselect.makeopts" file that indicates that chan_h323 should be built. However, after re-running the configure script to make it ignore certain libraries on the system, it can no longer be built. I think this is an acceptable situation to ask for user intervention. It would obviously be very easy to just ignore the situation and generate a new menuselect.makeopts file, but it is done this way to make it obvious to the user what is going on. |