Request to add a Port for the Codegroup CLI Program

[RobK88]

I would like to see Macports add a port for the codegroup program. It is useful for ham radio where one wants to transmit a binary file using only alphanumeric characters.

The web page and source code is found here: ​https://www.fourmilab.ch/codegroup/

The source is in the public domain. From the man page:

This software is in the public domain. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, without any conditions or restrictions. This soft- ware is provided as is without express or implied warranty.

A makefile is provided. The source compiles fine on my Mac running Lion. The tests in "make check" also complete without any errors. I have also been able to use the software without any issues so far.

But please note that one needs to manually install the binary and man page into the right directories because the developer failed to include "make install" in the makefile.

It should be easy to create a portfile.

[reneeotten (Renee Otten)]

Replying to RobK88:

I would like to see Macports add a port for the codegroup program. It is useful for ham radio where one wants to transmit a binary file using only alphanumeric characters.

<snip>

It should be easy to create a portfile.

Please feel free to give that a try and ask questions here if you run into trouble. (I don't know why kencu was added here to CC, so removing that; of course if you want to be on CC feel free to add yourself again Ken).

[RobK88]

Attached is my first attempt at creating a portfile. Please note that the source did not include a configure script or a "make install" in the makefile. So I included "use_configure no" in the portfile and added some lines to manually move the binary, man page etc into the right directories. I am not sure if I got the permissions right.

Please review my portfile and comment.

P.S. I still need to figure out how to create a local repo so I can test the portfile.

Many thanks!

[RobK88]

First attempt at a portfile for codegroup program

[RobK88]

I failed to mention that the software does not have a version number. But since it appears that this is the fourth release, I created one -- 4.0

Or should I use the date as the release in the portfile instead (e.g. 7th September 2008) ?

P.S. There does not appear to be any dependencies other than the C std library. So no dependencies were declared in the portfile.

rob$ otool -L codegroup
codegroup:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

[kencu (Ken)]

looking good!

1. as there is no version in the source zip name, I would be inclined to use the date as the version (20080907). If John ever updates it, the new code.zip will likely also have no version it I guess, and the date of the new release will become the new version.

2. When you are building this, check to see if the Makefile uses the proper compiler, etc, during the build. Perhaps try to build it universal, and see if it builds universal. You will likely find out it does not, and if so, you can explore adding the "Makefile 1.0" PortGroup that usually will make things work by setting up the proper environment variables in the background.

3. I have spent many hours exploring John Walker's websites and intellectual meanderings, and when he ran "RatBurger" I would hang out there as well. Very interesting story behind John, his early successes with AutoDesk, his wealth and move to Switzerland, and his adventures since. I had a serious talk with a friend two years ago about duplicating his trip to the North Pole on the Russian icebreaker. We may still do it!

[kencu (Ken)]

When this gets to the stage of a pull request, there will be some minor fixes suggested. master_sites is usually just a URL to the directory where the source file is stored, not the full URL to the file (I didn't know that would work, actually). To force the source file name to be what you want instead of the one that MacPorts will automatically generate ($name-$version.$extension) you override the defaults with $distname, which then gets made into a final filename of $distname.$extension .

There are hundreds of idiosyncracies like that in MacPorts that make it harder for people to get started writing Portfiles, but make it easier for people who already know how to write Portfiles. That kind of decision-making has led to a rather high bar being set for new contributors to MacPorts.

For homebrew, for example, you would just do "brew create FULL_URL" to your source, and your formula is done. The URL to the file is just the full simple URL, no confusion, anyone can see what it is. Less flexible in ways, mirroring distfiles is harder, etc -- but much simpler for new contributors to understand.

Design choices -- ups and downs to them.

[RobK88]

Thanks Ken for all your input!

I have changed the version number to a date as per your suggestion.

I also changed master_sites to the directory on the website where the source file is located. (In this case master_sites is the same as homepage). I assume Macports will be able to download it because the file name is the same as the name of the port (with .zip added). ("use-Zip yes" is included in the portfile).

And you are right. The Makefile is really basic. Other than setting CFLAGS, there is really no attempt to make sure that the right compiler is used. I suspect that any C compiler would work since the program is really basic and quite short. In any event, I added "PortGroup Makefile 1.0" to the portfile as per your suggestion.

I will attach Rev 2 of the portfile.

P.S. I could not find any reference to "PortGroup Makefile 1.0" in the Macports manual. If I have any complaints regarding Macports, it is the documentation which is lacking in places making it hard for newbies like me to learn how to properly write portfiles.

P.P.S. I hope you make the trip to the North Pole. That sounds like a real adventure!

[RobK88]

portfile Rev 2

[RobK88]

Added distname to portfile

[RobK88]

small change to distname

[RobK88]

I finally setup a local rep and was able to test the portfile and work out some bugs. I found out two bugs:

1) The license must be one word. ie. "Public Domain" does not work! One must use "PublicDomain" instead. 2) I needed to set workscrdir in the portfile.

I will attach the portfile that works!

Now I need to find out how to submit the portfile to the Macports developers for inclusion into the port tree.

[RobK88]

Final version of portfile for codegroup. This appears to work just fine!

[RobK88]

Didn't realize that I needed to run the following as a final check.

port lint --nitpick codegroup

Made minor correction! Will attach portfile.

[RobK88]

the FINAL FINAL version ofthe portfile.

[RobK88]

I submitted the portfile to Macports for consideration. #64032

Ken -- Thanks for all your help!

[ryandesign (Ryan Carsten Schmidt)]

No need to submit another ticket; this one is fine.

[ryandesign (Ryan Carsten Schmidt)]

In b186710d9168ac6791589f400bf7b03d87da4665/macports-ports (master):

codegroup: New port, version 20080907

Closes: #63972

[ryandesign (Ryan Carsten Schmidt)]

Thanks for your contribution. I committed it with several changes:

• Tightened up the whitespace.
• Added your GitHub handle to your email address in the maintainers line.
• Rewrapped the description and long description to max 72 characters.
• Corrected license to "public-domain".
• Avoided repeating things by referencing homepage in the definition of master_sites.
• Used the unversioned distfile recipe (specified dist_subdir).
• Used extract.mkdir yes instead of worksrcdir ./.
• Removed use_configure no because the makefile portgroup sets that for you.
• Removed test.run yes because the Makefile doesn't have any test targets.
• Added a patchfile to fix the Makefile so that it honors MacPorts-supplied CFLAGS and LDFLAGS, necessary to support building for non-default architectures and universal. (The way to have determined that this was necessary was to build the port and examine the logfile and notice that the lines that invoke the compiler didn't have the -arch flags that MacPorts supplies.)
• Removed lines from destroot that created standard directories that MacPorts already creates for you.

You're right that the makefile 1.0 portgroup is underdocumented. Anyone may submit documentation. Whenever documentation for a portgroup does not exist, reading the portgroup code is recommended.

[ryandesign (Ryan Carsten Schmidt)]

In 4b895cbda04c2a9270da254f88615dbda3af041e/macports-ports (master):

codegroup: Fix capitalization of makefile portgroup

See: #63972

[RobK88]

Many thanks Ryan.

I wasn't sure how to handle CFLAGS and LDFLAGS in the Makefile given that Macports must be using its own flags. Now I know how to handle them. One must patch the Makefile!

I was thinking of using extract.mkdir given the flat file structure of the distribution zip file but could not figure out extract.mkdir. I found the documentation on that keyword to be a little confusing. Now it makes sense once I see it in action.

Not a big deal but I still do not know why you deleted "test.run yes". The makefile does have "make test" defined. I must be missing something.

Again thanks for all your feedback. I learned a lot.

[ryandesign (Ryan Carsten Schmidt)]

Replying to RobK88:

I wasn't sure how to handle CFLAGS and LDFLAGS in the Makefile given that Macports must be using its own flags. Now I know how to handle them. One must patch the Makefile!

Custom Makefiles, like the one this project uses, are, well, custom. Each one is different. One hopes the developers of any build system would anticipate the user's need to specify CFLAGS and LDFLAGS but many custom Makefiles like this one do not. In such situations, one often must patch them. Ideally, one would contribute the patch back to the developers so that they can include it in the next version, and after we update to the new version then we won't have to patch anymore. But if the project is no longer being developed then that doesn't apply. I don't know whether this project is still being developed. You could try to contact the developer to find out.

Not a big deal but I still do not know why you deleted "test.run yes". The makefile does have "make test" defined. I must be missing something.

With test.run yes in the Portfile, trying to run sudo port -d test codegroup failed with the message:

make: *** No rule to make target `test'.  Stop.

There is no test target in the Makefile. That's why I removed test.run yes—it didn't work.

Looking at it more closely, I see that there is a check target, and that does seem to work, so I'll enable it in the Portfile.

[ryandesign (Ryan Carsten Schmidt)]

In 0950d02ca0da650d71f57b0fb0566d6518bb2ffe/macports-ports (master):

codegroup: Enable tests

See: #63972

[RobK88]

Thanks Ryan. I did not realize that the default target for running tests is "test" not "check". I see it is easy to fix by using the "test.target" keyword in the portfile.

And it looks like the project is no longer being developed. The last update was in 2008. I doubt there are any major bugs in it though since the source code is a pretty straightforward and short written in c.