Bug 628549 - Make 3.82 picks wrong rule
Summary: Make 3.82 picks wrong rule
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: make
Version: 14
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Petr Machata
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F14Beta, F14BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2010-08-30 11:17 UTC by Mattias Ellert
Modified: 2015-05-05 01:35 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-01 04:48:49 UTC
Type: ---
Embargoed:


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

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".


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