Bug 628549

Summary: Make 3.82 picks wrong rule
Product: [Fedora] Fedora Reporter: Mattias Ellert <mattias.ellert>
Component: makeAssignee: Petr Machata <pmachata>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 14CC: mnewsome, pmachata
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-01 04:48:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 611991    
Attachments:
Description Flags
Simplified makefile that illustrates the problem none

Description Mattias Ellert 2010-08-30 11:17:48 UTC
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 13:02:53 UTC
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 14:12:09 UTC
(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".