Good news, Claude (the AI thing) was finally able to convert to GO script into a [/icode]shell[/icode] script, that compile the libraries and the binary and copies all the artifacts in the right places.
I am going to run further test and then I will work on create the port.
I hope I am not infringing any rules by using a LLM assistant to create this port...
so far I managed to create the rules for built the development cycle, but this software comes in stable and development; I wonder if I should create a different binary for each version or place a rule that if you use stable you cannot use devel, and therefore one uninstall the other.
but this software comes in stable and development; I wonder if I should create a different binary for each version or place a rule that if you use stable you cannot use devel, and therefore one uninstall the other.
There is a Makefile option called CONFLICTS_INSTALL for these situations. I am not sure but the right procedure might be creating 2 port directories, one is for devel package and stable package without any pkg namesuffix. I guess poudriere and poudriere-devel might be a good example. Good luck!
I think the problem is there are two use cases. An individual like you or I wants to build a port with the least effort necessary. In contrast, the FreeBSD package system MUST build everything. The package system isn't penalized like us for situations like the one you describe.
You have to learn the entire ports framework which is too much asked for a 1000 lines single-file program. Using FreeBSD for 20 years but I never made an official port because it's a massive maze that takes too much time with few results. I would contribute to a program that covers it in tree-style using checkboxes. Processing a list of supposed standardized things that have to happen to create a working ports-entry that installs and builds using make shoudn't be that complex. Quite sure it can't be done because the exact requirments aren't clear and also can change with major versions. An idea is to create a concept portstree with 1 port and document the function of all involved files that are not part of the program itself.
You have to learn the entire ports framework which is too much asked for a 1000 lines single-file program. Using FreeBSD for 20 years but I never made an official port because it's a massive maze that takes too much time with few results. I would contribute to a program that covers it in tree-style using checkboxes. Processing a list of supposed standardized things that have to happen to create a working ports-entry that installs and builds using make shoudn't be that complex. Quite sure it can't be done because the exact requirments aren't clear and also can change with major versions. An idea is to create a concept portstree with 1 port and document the function of all involved files that are not part of the program itself.
The best starting point would be reading different but similar ports as you want to port and see what they do. And read Porter's Handbook with Mk/bsd.port.mk for anything you cannot understand what's done.
The best starting point would be reading different but similar ports as you want to port and see what they do. And read Porter's Handbook with Mk/bsd.port.mk for anything you cannot understand what's done.
That's approach from the wrong side, in my opinion. I made hello_world.c. Where can I find the things that are needed to make it a port that can be built and installed with the "make install" command? This is a checklist...
That's approach from the wrong side, in my opinion. I made hello_world.c. Where can I find the things that are needed to make it a port that can be built and installed with the "make install" command?
You don't need to do so if you don't want to share your efforts with others.
And note that some of dependencies could "fit" for FreeBSD using ports framework, making things differ from the upstream assumes.
This often happenes when multiple versions of something are sanely coexisiting while upstreams assume all versions to be installed in same directories with same filenames.
I decided to pursue the strategy to not let the two versions coexist at the same time. Jails can help to have stable and dev coexisting on the same OS.
It is better to work daily on the "devel" version and have the "stable" on a jail in my opinion...
You don't need to do so if you don't want to share your efforts with others.
And note that some of dependencies could "fit" for FreeBSD using ports framework, making things differ from the upstream assumes.
This often happenes when multiple versions of something are sanely coexisiting while upstreams assume all versions to be installed in same directories with same filenames.
devel/hello_world has no dependencies and only 1 version. It's on my github.
First thing needed: a working Makefile that fetches the source file and registers the package hello_world. The result is /usr/local/bin/hello_world existing and pkg info showing it as installed package.
If the next version gets more complex, we can look at new requirements to keep it working as a port, but that's irrelevant for now...
That's approach from the wrong side, in my opinion. I made hello_world.c. Where can I find the things that are needed to make it a port that can be built and installed with the "make install" command? This is a checklist...
If you don't have a Makefile, you'll need to use do-build: and do-install: and USE_GITHUB.
Examples: x11/xrsi, x11/xtrlock, x11/mons
If no version is available, use DISTVERSION=gYYMMDD and GH_TAGNAME=.
If you don't have a Makefile, you'll need to use do-build: and do-install: and USE_GITHUB.
Examples: x11/xrsi, x11/xtrlock, x11/mons
If no version is available, use DISTVERSION=gYYMMDD and GH_TAGNAME=.
No.
/usr/ports/distfiles/ is the default directory for ports framework to store fetched distfiles of EVERY ports. Some create subdirectories there.
And poudriere allows setting different place to fetch distfiles, isolated from default place. This would be because fetching the same distfiles multiple time force upstream infrastructure to be overbloated.
Not sharing /usr/ports/distfiles within bare-metal and poudriere is simply silly and unrespectful impolite thing to upstream. I don't think DISTFILE_CACHE variable is even worth existing.
Poudriere is making everything more complex than it should it be, which is already complicated; I think I'll move the ports from the VM to the host, since Hopefully the ports are ready for submission.
It need not be in /usr/ports. For example, if you did a 'git clone' of freebsd-ports to a different directory, you could use that.
To protect my own sanity when doing this kind of work, I create a separate branch for the new code. I can do a diff between main and working branches to confirm changes. Since your work spans multiple ports, you may need to separate them into different branches. If the ports are tightly coupled it would make sense to me to include them all in the same "hail mary" patch but that also makes the size of the review larger. You could start with the port with the least dependencies and submit that first. Some of the feeback would likely apply to the other ports. I leave that choice up to you.
Submit a git-diff style patch created from the port's own working directory. Do a make clean first so that only the minimum number of files remain. Also, the patch should be flattened so that, when applied, it appears as a single commit. Attach the patch to a new issue in bugzilla.
A more elaborate way is to use phabricator. Given the size of your patch (multiple ports), this may be better.
Odds are you will get some feedback in the review. The wiki page above describes a tool called arcanist that helps streamline the process of updating your patch.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
