Ticket #382 (closed bug: fixed)

Opened 13 years ago

Last modified 12 years ago

Using := in Makefiles causes extra complexity

Reported by: dukeleto Owned by: coke
Priority: normal Milestone:
Component: core Version:
Severity: medium Keywords:
Cc: rg@… Language:
Patch status: Platform: freebsd

Description (last modified by Infinoid) (diff)

When Configure.pl detects gmake in your $PATH, it assumes you intend to use it, and allows ":=" syntax in the Makefile it generates. Thus, when gmake is installed, you are forced to use it (even when it's not the normal "make" for your platform). See discussion below.

Attachments

freebsd-make-error.txt Download (14.5 KB) - added by dukeleto 13 years ago.
output of perl Configure.pl && make
make.patch Download (424 bytes) - added by rg 13 years ago.

Change History

Changed 13 years ago by dukeleto

output of perl Configure.pl && make

  Changed 13 years ago by coke

  • owner set to coke

Normally, I would suspect this implied a makefile dependency problem, but after a realclean, at r37032,

make realclean; perl Configure.pl && make -j7 src/pmc/sub.str

works fine; Can you try a realclean (I feel like tech support asking you to reboot) and see if the problem persists?

  Changed 13 years ago by dukeleto

It turns out that I was using FreeBSD make instead of gmake. When I use gmake, everything is fine.

Since the instructions specifically say "gmake", this is not a problem.

User Error. Please close ticket.

  Changed 13 years ago by coke

  • status changed from new to closed
  • resolution set to invalid

follow-up: ↓ 5   Changed 13 years ago by rg

  • cc rg@… added

Actually that's not entirely true, but it hasn't bothered me enough to complain, yet. The thing is, if you didn't have gmake installed it would just say to "use 'make' to build your Parrot", without ever complaining that it wasn't gnu make (and therefor going to fail). This is especially true for Solaris, which even chokes on the := assignments.

I think what we need (at least for now) is a check to make sure make (or gmake) is actually gnu make. Since this is kind of a policy question and I don't intend to write that test, I'll leave this ticket closed, but maybe some discussion is warranted.

in reply to: ↑ 4 ; follow-up: ↓ 6   Changed 13 years ago by fperrad

Replying to rg:

Actually that's not entirely true, but it hasn't bothered me enough to complain, yet. The thing is, if you didn't have gmake installed it would just say to "use 'make' to build your Parrot", without ever complaining that it wasn't gnu make (and therefor going to fail). This is especially true for Solaris, which even chokes on the := assignments.

Fixed by r37086, I hope.

I think what we need (at least for now) is a check to make sure make (or gmake) is actually gnu make. Since this is kind of a policy question and I don't intend to write that test, I'll leave this ticket closed, but maybe some discussion is warranted.

in reply to: ↑ 5   Changed 13 years ago by rg

Replying to fperrad:

Replying to rg:

Actually that's not entirely true, but it hasn't bothered me enough to complain, yet. The thing is, if you didn't have gmake installed it would just say to "use 'make' to build your Parrot", without ever complaining that it wasn't gnu make (and therefor going to fail). This is especially true for Solaris, which even chokes on the := assignments.

Fixed by r37086, I hope.

That's helping for the problems on Solaris, thank you.

To fix the problem of this report, you'd also need to apply the patch I'm attaching. Note that the rule in question is not even required, since explicit rules for all files are generated. However for those versions of make that accept dependencies on those rules, this creates a cyclic dependency. As a result BSD make seems to prefer not to make anything (although it doesn't fail either), where gmake seems to break/ignore the cycle. Anyway, I think the dependency is bogus. Removing it fixes the build on FreeBSD with native make.

Changed 13 years ago by rg

  Changed 13 years ago by fperrad

Patch applied in r37098.

  Changed 13 years ago by doughera

  • status changed from closed to reopened
  • resolution invalid deleted

Unfortunately, this broke my build script (on Solaris). I did have gmake available in my PATH, but don't normally use it. Can we just get rid of the := assignments altogether? Do they really buy anything?

  Changed 13 years ago by fperrad

When 'gmake' is not detected as your make (by Configure), all ':=' are substituted by '='.

Most of the time, the configuration step config/inter/make.pm prefers 'gmake' if many make are available in PATH.

So, you could :

  • remove 'gmake' of your PATH, because you don't use it
  • force your favourite make with : perl Configure.pl --make=my_make

Currently, your configuration is not coherent, built with gmake and used without.

follow-up: ↓ 11   Changed 13 years ago by doughera

My configuration was "coherent" 2 weeks ago, and it hasn't changed. Nor has my build script changed. What has changed is that parrot now requires you to use gmake if it is available.

My question still is the same: "Can we just get rid of the := assignments altogether? Do they really buy anything? As far as I can tell, they just add pointless complexity for no gain. Yes, I can work around the pointless complexity on parrot's end by adding compensating complexity on my end, but it all seems rather pointless.

in reply to: ↑ 10   Changed 13 years ago by rg

Replying to doughera:

My question still is the same: "Can we just get rid of the := assignments altogether? Do they really buy anything?

I was wondering that, too. However, there is at least one more thing that's changed when gmake is detected: we are using the -C option (which is also missing from Solaris make) instead of a rather unwieldy call to perl -e.

As to why we're maintaining both alternatives instead of deciding to either a) be compatible with the worst make out there or b) require gmake (if that is even possible for windows), I have no idea.

  Changed 13 years ago by doughera

Just as a further data point -- I got bit by this again as I tried to do some final testing leading up to 1.0. I had forgotten to update my try-them-all build script, and they all failed for no good reason. Aargh.

  Changed 13 years ago by coke

  • status changed from reopened to new
  • owner coke deleted

  Changed 13 years ago by rg

  • summary changed from make fails on freebsd 6.2/gcc 3.4 to Using := in Makefiles causes extra complexity

Updated the summary, but the original description also no longer applies, however I can't edit it. The original reporter probably also doesn't care. Maybe we should open a new ticket?

  Changed 13 years ago by Infinoid

  • description modified (diff)

rg, I've updated the description for you. +1 for being compatible with the worst make out there, and getting rid of :=.

  Changed 12 years ago by coke

  • owner set to coke

follow-up: ↓ 18   Changed 12 years ago by coke

branches/one_make has eliminated the use of the :=, except for one case that will only occur on darwin.

Once that branch is merged back, this ticket can be closed.

in reply to: ↑ 17   Changed 12 years ago by jkeenan

  • status changed from new to closed
  • resolution set to fixed

Replying to coke:

branches/one_make has eliminated the use of the :=, except for one case that will only occur on darwin. Once that branch is merged back, this ticket can be closed.

After the merge at r43593, this grep was run, confirming Coke's estimate:

fns . | grep -i Makefile | xargs grep -n ':='
./ext/SQLite3/Makefile.in:40:#IF(darwin):export 
  MACOSX_DEPLOYMENT_TARGET := @osx_version@
./config/gen/makefiles/root.in:540:#IF(darwin):export 
  DYLD_LIBRARY_PATH := @blib_dir@:$(DYLD_LIBRARY_PATH)

Closing ticket.

Thank you very much.

kid51

Note: See TracTickets for help on using tickets.