search

SDL-Hercules-390 / hyperion

The SDL Hercules 4.x Hyperion version of the System/370, ESA/390, and z/Architecture Emulator
Other
240 stars 90 forks source link

Make dist no longer works #123

Closed ivan-w closed 5 years ago

ivan-w commented 6 years ago 
$ make dist
make  dist-gzip am__post_remove_distdir='@:'
make[1]: Entering directory '/home/ivan/hercules/build/fh-dist'
make[1]: *** No rule to make target 'BUILDING', needed by 'distdir'.  Stop.
make[1]: Leaving directory '/home/ivan/hercules/build/fh-dist'
Makefile:2486: recipe for target 'dist' failed
make: *** [dist] Error 2
Fish-Git commented 6 years ago

Forgive my ignorance, but is make dist even still needed these days? Isn't the repository itself "the distribution" now? What does make dist do other than build a source tarball with a configure script?

ivan-w commented 6 years ago

No, because configure and such are GENERATED files... Not SOURCE files... Make dist allows one to create a proper tarball appropriate for distribution... Or at least that's how multiple thousands of projects work..

mhoes commented 6 years ago

Forgive my ignorance, but is make dist even still needed these days? Isn't the repository itself "the distribution" now? What does make dist do other than build a source tarball with a configure script?

I guess some of the answer to that depends on whether you want to do an 'official/stable' release again, as in ever. If you just want people to always 'just clone/pull whatever currently is in git, and see if it works for you', then perhaps you don't need any 'blessed/official/stable' 'releases' anymore.

But that's not what you seem to be doing with the Windows builds over at your website. Although the point at which one chooses to create a 'release' may up to some point always at least be somewhat arbitrary, you do seem to still do 'releases', at least for the Windows builds. You may want to do the same for the Unix/Linux release, either in pre-build or in source tarball form.

At which point, a make 'target' which automates this for you seems appropriate. You may then want to make these source tarball distributions available on the 'releases' tab of github.

Again, just my 2$ cents.

Fish-Git commented 6 years ago

I guess some of the answer to that depends on whether you want to do an 'official/stable' release again, as in ever. If you just want people to always 'just clone/pull whatever currently is in git, and see if it works for you', then perhaps you don't need any 'blessed/official/stable' 'releases' anymore.

Maybe we just need to start "tagging"(?) (not sure if that's the right term) certain commits (branches?) as being the next "blessed/official/stable release"? I mean, I think I see your point: simply cloning or downloading the current repository (as it appears at that exact moment in time) might not get you a working, stable version of the product! (since after all the repository is just a development repository constantly "in flux")

Thus the need for periodic "official releases", which, if I'm understanding things properly, is what make dist is for: generating (creating) "official release tarballs". A type of "pre-built" like we're doing with Windows, but in source form instead.

Or... we could just periodically download the .zip file from GitHub whenever we feel an "official release" should be done, and simply publish those zip files somewhere. Those would then be the equivalent of an official release tarball.  <shrug>

The point I'm trying to make is, except for the "stability" aspect mhoes has brought up, a make dist tarball is essentially no different than what our GitHub repository currently provides: everything needed to build the product for yourself!

Fish-Git commented 6 years ago

I said:

Or... we could just periodically download the .zip file from GitHub whenever we feel an "official release" should be done, and simply publish those zip files somewhere. Those would then be the equivalent of an official release tarball.

mhoes said:

At which point, a make 'target' which automates this for you seems appropriate. You may then want to make these source tarball distributions available on the 'releases' tab of github.

Which sounds like the perfect place for our periodic pseudo "make-dist" releases I suggested we should maybe start doing!

Basically there's no longer any need to be doing any make dist any longer now that GitHub provides a "Download" button. Instead, we simply choose whichever commit we feel is "stable" and the one we want to "officially release", and download that .zip file and publish it on the GitHub "Releases" tab!

Would that work?

mhoes commented 6 years ago

Maybe we just need to start "tagging"(?) (not sure if that's the right term) certain commits (branches?) as being the next "blessed/official/stable release"?

I do believe the proper git term here would be a 'branch', which as far as i know (which is not much, I must admit), exactly that: at 'some point' you 'branch', and 'all that currently is in the main/master version' gets copied to that, and then you can do 'only bug fixes' on that branch without it affecting the main/master version, where feature development occurs (in addition to bug fixes, which you then may or may not want to apply to any given other branch as well).

The point I'm trying to make is, except for the "stability" aspect mhoes has brought up, a make dist tarball is essentially no different than what our GitHub repository currently provides: everything needed to build the product for yourself!

Except, of course, for the point of 'including or not' any build system generated files ('configure', 'config.h.in', 'Makefile.in', and friends), which may be nice or even required additions to a source tarball release, but may not be appropriate for inclusion in the source code revision system.

mhoes commented 6 years ago

Would that work?

Perhaps it would, it just does not seem to be the current practice used by other open source projects that I know of (hosted on github or not).

mhoes commented 6 years ago

Side note: I do have to admit, that I am starting to feel a little like this guy here ;)

https://www.xkcd.com/386/

Fish-Git commented 6 years ago

Or at least that's how multiple thousands of projects work..

Amusing anecdote:

Back in the days of WWII, a freshly promoted U.S. Army Lieutenant was assigned to the division responsible for the manufacture of all leather goods required by the Army. Bomber seats, bomber jackets, pistol holsters and belts, etc, and placed in charge of ensuring the steady supply of llama dung coming from the llama farms in South America wasn't interrupted, lest it impede the war effort. It seems it was in the military regulations that all leather goods had to be treated with llama dung before being sent out in the field!

Llama dung? wtf?

Well, being the person he was, questioning anything that didn't make sense to him, he asked his superiors what was the basis for the "llama dung" requirement? None of them could explain it to him. They all essentially said "That's just the way we've always done it."

Not being satisfied with such an answer he went about digging through the regulation's history and discovered it had been in the regulations ever since the very beginning of this great country! The Revolutionary War! But still no answer as to why it was in the regulations.

Researching further he discovered much to his dismay that the U.S. Military Regulations were essentially copied from the British Military Regulations at the time, where he finally found his answer:

It seems back in the days of the Revolutionary War, the Cavalry was an important division of the military and the British happened to notice their horses behaved quite skittishly when fitted with freshly tanned saddles and reins. Apparently the smell of freshly tanned leather didn't appeal to them. But when treated with llama dung, it masked (diminished) the smell of the tanning and the horses calmed down.

So the moral of the story is: just because something has "always been done that way" doesn't mean it still applies today. You need to periodically dust off your preconceptions and ask yourself whether the reason for doing something a particular way still applies or whether it's been rendered obsolete by a new, better way of accomplishing the same thing. (Times change after all.)

So whenever anyone says we have to do it this way or that way because that's the way everyone else is doing it (or because that's the way it's always been done), just lift your head slightly, take a few sniffs, and then ask them:

"Do you smell that?  Smells like llama dung, doesn't it?"

p.s.  In case any of you were wondering, the above story is of course not true! It's completely made up. I first heard it many years ago very early in my career and it has stuck with me all these years.

mhoes commented 6 years ago

Nice anecdote.

just because something has "always been done that way" doesn't mean it still applies today.

True.

You need to periodically dust off your preconceptions and ask yourself whether the reason for doing something a particular way still applies or whether it's been rendered obsolete by a new, better way of accomplishing the same thing. (Times change after all.)

Equally true.

However, the exact opposite is equally true: just because something is done a certain way today, that doesn't make it wrong by definition. It could also be that for valid reasons, time has shown it to be the best way we know how to do it.

Oh, did I mention I find it a nice anecdote?

mhoes commented 6 years ago

Well, if we expand on that logic, then - in the age of github - there is no longer a need to do any 'releases' whatsoever anymore (or inclusion of 'licenses', apparently: the most of the projects on github no longer seem to include an explicit specific license, not even the 'do what the fuck you want license'); people can just go 'git clone/pull' or 'download the zip' and we're done!

Fish-Git commented 6 years ago

people can just go 'git clone/pull' or 'download the zip' and we're done!

That's the basic idea, yes.

However, ... it doesn't deal with the stable release issue you raised earlier. That, I believe, is a legitimate argument in favor of make dist .. OR, at the very least, my idea of periodically publishing downloadable .zip files on our "Releases" tab (or elsewhere, perhaps even on one of our web pages).

mhoes commented 6 years ago

Hrm. I was about to make a really shitty response here, but stopped myself. In fact, reading back my own posts, I feel I already have been making some pretty shitty posts already, for which I would like to apologize at this point. The only point I wanted to make was this: "Hey, I feel these files should not be in git, kay thx bye!", and leave it at that (which, by the way, is another issue). Sorry for the crap.

Fish-Git commented 6 years ago

Sorry for the crap.

What crap? Your comments seem perfectly fine to me!

mhoes commented 6 years ago

Thanks, perhaps the things I posted were not as harsh as I imagined. Anyways, my key point here can still pretty much be summed up as this :

"Hey, I feel these files should not be in git, kay thx bye!"

And yes, I do pretty much agree with ivan-w 's points for not including these files in git.

But perhaps I should try to leave it at that, at least for now, especially as it does not really hit me as a 'non-committer' with my shell-script work-around, even though 'co-committers' may experience more troubles (perhaps I should not try to speak for them, or anyone, really). Will try to stop here and just see you in the next git-issue or mailing list discussion!

Fish-Git commented 6 years ago

@ivan-w,

Let's return back to the original problem:

$ make dist [...] make[1]: Entering directory '/home/ivan/hercules/build/fh-dist' make[1]: *** No rule to make target 'BUILDING', needed by 'distdir'. Stop.

What does that mean? How do we fix it?

I myself have never tried doing a make dist before, so I'm not familiar with what's involved. What are the requirements? What are the pre-requisites? Why is this bug occurring? Why is make dist trying to "build" our BUILDING document? What do we need to do to fix this problem? Does anyone know?

ivan-w commented 6 years ago

Ok, here is more context:

The intent of make dist is to create a tar file which contains everything that is needed to build a project on a specific environment from source using the required compilers and development version of libraries (and maybe some other dependencies, but not the autoxxx tools). So the tar ball will contain a configure script, but no "Makefile".

  A proper build cycle (including validation test of the build environment itself) when pulling from a repository is to run:

  Pros:

  Cons:

  As to why it no longer works (it used to works years ago...) I haven't really looked into it...

Fish-Git commented 5 years ago

Ok, here is more context:

Thank you for that. I will give it a try myself when I get the time.

As to why it no longer works (it used to works years ago...) I haven't really looked into it...

I'll try to give it a try myself when I find the time and let you know. It's probably something simple like a missing file or two in makefile.am.

Fish-Git commented 5 years ago

I will give it a try myself when I get the time.

Okay, I took the time to try and add all of the missing files to all of the Makefile.am files and afterwards tried your procedure (autogen, configure, make dist) and it's bombing on bldlvlck even though it's clearly listed in the util/Makefile.am file! (It was originally erroneously listed in the root Hercules source dir's Makefile.am, but I removed it from there.)

I don't know enough about how to properly do things on Linux and we've obviously been overly careless over the years with regard to properly maintaining our autoconf files and I don't have the skills or knowledge to fix whatever's broke.

So I've given up. :(

Unless someone else more knowledgeable/skilled wants to take the time and effort to fix things so make dist works, I'm afraid it's never going to work.

I'm going to close this issue just to get it off our list even though it hasn't been resolved since I doubt it will ever get properly resolved.

You are (or anyone else is!) free to re-open this issue should you wish to take a crack at trying to resolve it.

Thanks.