Bug 628549 - Make 3.82 picks wrong rule
Make 3.82 picks wrong rule
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: make (Show other bugs)
14
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Petr Machata
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F14Beta/F14BetaBlocker
  Show dependency treegraph
 
Reported: 2010-08-30 07:17 EDT by Mattias Ellert
Modified: 2015-05-04 21:35 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-01 00:48:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Simplified makefile that illustrates the problem (264 bytes, text/plain)
2010-08-30 07:17 EDT, Mattias Ellert
no flags Details

  None (edit)
Description Mattias Ellert 2010-08-30 07:17:48 EDT
Created attachment 441931 [details]
Simplified makefile that illustrates the problem

Description of problem:
The make version in F14 (3.82) picks the wrong rule - causing FTBFS errors for other packages:

See e.g.: https://koji.fedoraproject.org/koji/buildinfo?buildID=192718

Version-Release number of selected component (if applicable):
make-3.82-1.fc14.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Try running make with the attached makefile

Actual results:

On Fedora 14 (make 3.82) - wrong:

$ make
Second
Second
rm cint/cint/lib/posix/exten.c cint/cint/lib/G__c_posix.c

Expected results:

On Fedora 12 (make 3.81) - correct:

[ellert@ellert mktest]$ make
First
Second
rm cint/cint/lib/posix/exten.c cint/cint/lib/G__c_posix.c
Comment 1 Petr Machata 2010-08-30 09:02:53 EDT
There was a change of behavior in make in this respect:

> If a target matches more than one pattern, the matching pattern-specific
> variables with longer stems are interpreted first. This results in more 
> specific variables taking precedence over the more generic ones.

In your case, changing your "G__c_%.o: G__c_%.c" rule to qualify the directory explicitly, like "cint/cint/G__c_%.o: cint/cint/G__c_%.c" should take care of this problem.  Or are there more G__c_% files in other directories of the build?
Comment 2 Mattias Ellert 2010-08-30 10:12:09 EDT
(In reply to comment #1)
> There was a change of behavior in make in this respect:
> 
> > If a target matches more than one pattern, the matching pattern-specific
> > variables with longer stems are interpreted first. This results in more 
> > specific variables taking precedence over the more generic ones.
> 
> In your case, changing your "G__c_%.o: G__c_%.c" rule to qualify the directory
> explicitly, like "cint/cint/G__c_%.o: cint/cint/G__c_%.c" should take care of
> this problem.  Or are there more G__c_% files in other directories of the
> build?

The makefile has rules for:

G__%.o: G__%.cxx
G__c_%.o: G__c_%.c
cint/cint/%.o: cint/cint/%.cxx
cint/cint/%.o: cint/cint/%.c
build/%.o: build/%.cxx
build/%.o: build/%.c
%.o: %.cxx
%.o: %.c

The first two rules are supposed to match the G__% and G__c_% files anywhere in the code tree - these files are autogenerated during the build so you can not simply look in the sources for where these files are. After a successful build (not using make 3.82) these following files exist:

./bindings/pyroot/src/G__PyROOT.cxx
./bindings/ruby/src/G__Ruby.cxx
./cint/cint/lib/dll_stl/G__cpp_climits.cxx
./cint/cint/lib/dll_stl/G__cpp_complex.cxx
./cint/cint/lib/dll_stl/G__cpp_deque.cxx
./cint/cint/lib/dll_stl/G__cpp_exception.cxx
./cint/cint/lib/dll_stl/G__cpp_list.cxx
./cint/cint/lib/dll_stl/G__cpp_map2.cxx
./cint/cint/lib/dll_stl/G__cpp_map.cxx
./cint/cint/lib/dll_stl/G__cpp_multimap2.cxx
./cint/cint/lib/dll_stl/G__cpp_multimap.cxx
./cint/cint/lib/dll_stl/G__cpp_multiset.cxx
./cint/cint/lib/dll_stl/G__cpp_queue.cxx
./cint/cint/lib/dll_stl/G__cpp_set.cxx
./cint/cint/lib/dll_stl/G__cpp_stack.cxx
./cint/cint/lib/dll_stl/G__cpp_stdexcept.cxx
./cint/cint/lib/dll_stl/G__cpp_valarray.cxx
./cint/cint/lib/dll_stl/G__cpp_vectorbool.cxx
./cint/cint/lib/dll_stl/G__cpp_vector.cxx
./cint/cint/lib/G__c_ipc.c
./cint/cint/lib/G__c_posix.c
./cint/cint/lib/G__cpp_stdcxxfunc.cxx
./cint/cint/lib/G__c_stdfunc.c
./cint/reflex/src/G__Reflex.cxx
./core/base/src/G__Base1.cxx
./core/base/src/G__Base2.cxx
./core/base/src/G__Base3.cxx
./core/clib/src/G__Clib.cxx
./core/cont/src/G__Cont.cxx
./core/editline/src/G__Editline.cxx
./core/meta/src/G__Meta.cxx
./core/meta/src/G__TCint.cxx
./core/metautils/src/G__MetaUtils.cxx
./core/rint/src/G__Rint.cxx
./core/thread/src/G__Thread.cxx
./core/unix/src/G__Unix.cxx
./geom/gdml/src/G__Gdml.cxx
./geom/geombuilder/src/G__GeomBuilder.cxx
./geom/geompainter/src/G__GeomPainter.cxx
./geom/geom/src/G__Geom1.cxx
./geom/geom/src/G__Geom2.cxx
./graf2d/asimage/src/G__ASImage.cxx
./graf2d/asimage/src/G__ASImageGui.cxx
./graf2d/gpad/src/G__GPad.cxx
./graf2d/graf/src/G__Graf.cxx
./graf2d/gviz/src/G__Gviz.cxx
./graf2d/postscript/src/G__PostScript.cxx
./graf2d/qt/src/G__GQt.cxx
./graf2d/x11/src/G__X11.cxx
./graf2d/x11ttf/src/G__X11TTF.cxx
./graf3d/eve/src/G__Eve1.cxx
./graf3d/eve/src/G__Eve2.cxx
./graf3d/g3d/src/G__G3D.cxx
./graf3d/gl/src/G__GL.cxx
./graf3d/gviz3d/src/G__Gviz3d.cxx
./graf3d/x3d/src/G__X3D.cxx
./gui/fitpanel/src/G__FitPanel.cxx
./gui/ged/src/G__Ged.cxx
./gui/guibuilder/src/G__GuiBld.cxx
./gui/guihtml/src/G__GuiHtml.cxx
./gui/gui/src/G__Gui1.cxx
./gui/gui/src/G__Gui2.cxx
./gui/gui/src/G__Gui3.cxx
./gui/qtgsi/src/G__QtGSI.cxx
./gui/qtroot/src/G__QtRoot.cxx
./gui/recorder/src/G__Recorder.cxx
./gui/sessionviewer/src/G__SessionViewer.cxx
./hist/hbook/src/G__Hbook.cxx
./hist/histpainter/src/G__HistPainter.cxx
./hist/hist/src/G__Hist.cxx
./hist/spectrumpainter/src/G__Spectrum2Painter.cxx
./hist/spectrum/src/G__Spectrum.cxx
./html/src/G__Html.cxx
./io/dcache/src/G__DCache.cxx
./io/io/src/G__IO.cxx
./io/rfio/src/G__RFIO.cxx
./io/sql/src/G__SQL.cxx
./io/xmlparser/src/G__XMLParser.cxx
./io/xml/src/G__XML.cxx
./math/fftw/src/G__FFTW.cxx
./math/foam/src/G__Foam.cxx
./math/fumili/src/G__Fumili.cxx
./math/genvector/src/G__GenVector32.cxx
./math/genvector/src/G__GenVector.cxx
./math/mathcore/src/G__MathCore.cxx
./math/mathcore/src/G__Math.cxx
./math/mathcore/src/G__MathFit.cxx
./math/mathmore/src/G__MathMore.cxx
./math/matrix/src/G__Matrix.cxx
./math/minuit2/src/G__Minuit2.cxx
./math/minuit/src/G__Minuit.cxx
./math/mlp/src/G__MLP.cxx
./math/physics/src/G__Physics.cxx
./math/quadp/src/G__Quadp.cxx
./math/smatrix/src/G__Smatrix32.cxx
./math/smatrix/src/G__Smatrix.cxx
./math/splot/src/G__SPlot.cxx
./math/unuran/src/G__Unuran.cxx
./misc/memstat/src/G__Memstat.cxx
./misc/memstat/src/G__MemstatGui.cxx
./misc/table/src/G__Table.cxx
./montecarlo/eg/src/G__EG.cxx
./montecarlo/vmc/src/G__VMC.cxx
./net/auth/src/G__RootAuth.cxx
./net/bonjour/src/G__BONJ.cxx
./net/krb5auth/src/G__Krb5Auth.cxx
./net/ldap/src/G__LDAP.cxx
./net/net/src/G__Net.cxx
./net/netx/src/G__Netx.cxx
./proof/clarens/src/G__Clarens.cxx
./proof/peac/src/G__Peac.cxx
./proof/peac/src/G__PeacGui.cxx
./proof/proofplayer/src/G__ProofDraw.cxx
./proof/proofplayer/src/G__ProofPlayer.cxx
./proof/proof/src/G__Proof.cxx
./proof/proofx/src/G__Proofx.cxx
./roofit/roofitcore/src/G__RooFitCore1.cxx
./roofit/roofitcore/src/G__RooFitCore2.cxx
./roofit/roofitcore/src/G__RooFitCore3.cxx
./roofit/roofit/src/G__RooFit.cxx
./roofit/roostats/src/G__RooStats.cxx
./sql/mysql/src/G__MySQL.cxx
./sql/odbc/src/G__ODBC.cxx
./sql/pgsql/src/G__PgSQL.cxx
./tmva/src/G__TMVA1.cxx
./tmva/src/G__TMVA2.cxx
./tmva/src/G__TMVA3.cxx
./tmva/src/G__TMVA4.cxx
./tree/treeplayer/src/G__TreePlayer.cxx
./tree/tree/src/G__Tree.cxx
./tree/treeviewer/src/G__TreeViewer.cxx

So these files are all over the place.

Also a rule like

cint/cint/G__c_%.o: cint/cint/G__c_%.c

will not work for files in subdirectories inside cint/cint because the % is not the first character in the filename pattern.

With the old way make was working writing the set of rules was easy, with the new way it has become very tricky to get it right. I find this change to long established behaviour very disruptive. Is there a better way to get this to work other than repeating the "G__%" and "G__c_%" rules for every subdirectory in cint/cint? It can of course be done - but it is quite verbose.

I guess this is a case of "one man's feature is an other mans bug".

Note You need to log in before you can comment on or make changes to this bug.