WIP: new Portfile submission: smalltalk

[artkiver (グレェ)]

Based off of ​https://github.com/dbanay/Smalltalk/ I have created a Portfile that is 90% of the way there.

In its current state: it will fetch the source, and build a binary, all well and good.

However, it fails during install because the Makefile from the upstream project is so sparse, it does not have an install to make! (Nor an "all" to make for that matter, but that is at least something which can be worked around a bit with build.target thanks to MacPorts and markh and khindenburg_ on IRC for helpful suggestions!)

Anyway, perhaps the best way to address this is to patch the Makefile?

Maybe someone else has a better approach?

Probably there is a better way to "version" this as well (I am just using the most recent git branch tag since there are no "release" nor "version" nor tarball to reference presently), maybe HEAD? I am open to suggestions for improvement!

I figured I would share the progress I have made thus far to at least get it off my local system, but additional effort is required to get this into a state which merits a PR.

[artkiver (グレェ)]

preliminary WIP Portfile for Smalltalk-80

[artkiver (グレェ)]

 < markh> grey: Use destroot.target if you need a different make target 
               other than "install", or destroot.cmd if you want a different 
               command.
03:23 < markh> btw these can all be found in man portfile

So, I will look into that next probably!

I need to stop staring at a screen for a little while, but am leaving this as a reminder for later (or if any curious individuals want to pick up where I left off, hopefully that is a helpful hint for what to tweak next?)

[ryandesign (Ryan Carsten Schmidt)]

Replying to artkiver:

However, it fails during install because the Makefile from the upstream project is so sparse, it does not have an install to make!

Replying to artkiver:

 < markh> grey: Use destroot.target if you need a different make target 
               other than "install", or destroot.cmd if you want a different 
               command.
03:23 < markh> btw these can all be found in man portfile

So, I will look into that next probably!

Sure, but as you said this Makefile does not provide any target for installation. You will have to either add one (and submit that to the developer) or else override the destroot phase and install everything manually with Tcl commands.

Probably there is a better way to "version" this as well (I am just using the most recent git branch tag since there are no "release" nor "version" nor tarball to reference presently), maybe HEAD?

It's not acceptable to use HEAD. You must use a specific tag or commit so that the build is reproducible.

I figured I would share the progress I have made thus far to at least get it off my local system, but additional effort is required to get this into a state which merits a PR.

Thanks! Note that you can file incomplete work as a PR. There is a way to mark a PR as a work-in-progress. The advantage is that it is easier to provide in-context reviews of your proposal there than here in Trac.

I am open to suggestions for improvement!

Here are some:

PortGroup           legacysupport 1.0

If you need legacysupport, please use the latest version, currently 1.1. But for what does this port require legacysupport? Add a comment and set the minimum Darwin version accordingly, as other ports that use the portgroups do. The legacysupport portgroup will not work until the Makefile is fixed to honor standard environment variables like CFLAGS, CXXFLAGS, and LDFLAGS. I can see by looking at the Makefile that it fails to mention LDFLAGS when it links the Smalltalk executable.

github.setup        dbanay smalltalk ab6ab55

Use the full commit hash, not an abbreviation.

When fetching an automatically-generated tarball from GitHub, set github.tarball_from archive. You will need to delete the old distfile from your system (e.g. with sudo port clean --all) and generate new checksums and put them in the Portfile.

It is fine to use a commit hash since there is no stable released version. But you must set version to a number that increases each time it is updated. (A git commit hash is thus not suitable as a version.) version 20230420 would be a good value, since that is the date of this commit.

Add the line revision 0.

long_description    Welcome to my "by the Bluebook" C++ implementation \
                    of the Smalltalk-80 system that runs on OS X, Windows, \
                    Linux, OpenBSD, and FreeBSD!

Whose is "my"? I would at least delete "Welcome to my" from this description. "OS X" should be spelled "macOS", but I'm not generally a fan of port descriptions that mention all the systems it runs on. All most users care about is whether it runs on their system, and it is a given that software in MacPorts runs on macOS.

use_configure       no

Anytime you see this, it is a red flag that you should remove it and instead include the makefile 1.0 portgroup. You will need to read and understand the Makefile in order to patch it or set the appropriate makefile portgroup variables to make it work. For handmade Makefiles like this one, there are no one-size-fits-all solutions.

For example, I see by reading the Makefile that it overrides the CC and CFLAGS environment variables, so the makefile portgroup will either need to be told to set those as args or the Makefile will need patching so CC is only set if not already set and CFLAGS are appended to rather than being overwritten. Ideally it would be structured in such a way that optimization flags MacPorts sets in CFLAGS and CXXFLAGS are not overridden by the Makefile.

I see that the Makefile misuses the CC variable as the C++ compiler and CFLAGS for the C++ compiler flags when they are supposed to be for the C compiler (and CXX and CXXFLAGS are supposed to be for the C++ compiler); this will need to be changed in the Makefile before things will work correctly. These are issues to be reported to the developers.

I see that it requests the C++ 2014 standard, so the Portfile will need compiler.cxx_standard 2014 added so that MacPorts will pick a compatible compiler.

[artkiver (グレェ)]

Replying to ryandesign:

Awesome! Thank you for the informative and thorough reply!

Yesterday was full of errands, today had some more chores and work and I am scheduled to work tomorrow as well, with a class on Monday and probably some other things on Tuesday so I won't get to this with much immediacy.

Regardless, I wanted to take a moment to appreciate all the thoughtfulness which went into your response. One of the reasons I have been enjoying collaborating on MacPorts is how much I learn in the process, and this has been no exception!