On 2018/08/03 12:23, Alessandro DE LAURENZIS wrote:
> I think we need the line:
>
> FAKE_FLAGS = PREFIX="${LOCALBASE}"
>
> since PREFIX is explicitly set to /usr/local in upstream Makefile when
> undefined.
That should probably be PREFIX="${TRUEPREFIX}"
> Also, in order to avoid python3 setup errors, I needed to set
>
> CONFIGURE_STYLE = none
Yep, long-known problem with python.port.mk
> Finally, portcheck gives the following message:
>
> Python module without compiled version, consider using ${MODPY_BIN}
> ${MODPY_LIBDIR}/compileall.py: share/yosys/python3/smtio.py
> cad/yosys
>
> I don't know if it's acceptable (and, if not, how to remove it...)
Python normally creates pyc files for imported modules if the directory
is writable. We pre-create these so that if e.g. someone runs the program
as root, we don't get stray pyc files left behind after uninstall.
You can remove it by using ${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py
to create the pyc file.
> - compiler name forced to eg++;
Don't hardcode this, use MAKE_FLAGS= CXX="${CXX}" etc.
> Different story for kernel/yosys.cc:
> - we need to include sys/wait.h;
> - code requires the process executable base path; Linux has /proc/self/exe
> and I see that there are solutions for APPLE and WIN32 too; OpenBSD doesn't
> have a ready-to-use function; this is the closest thing that comes to my
> mind:
>
> std::string proc_self_dirname()
> {
> // No direct way to get the process executable base path
> char path[PATH_MAX];
> ssize_t buflen = sizeof(path);
> char *res = realpath(getenv("_"), path);
> if (!res) {
> log_error("getenv(\"_\") failed: %s\n",strerror(errno));
> }
> *(strrchr(path, '/')+1) = '\0';
> while (buflen > 0 && path[buflen-1] != '/')
> buflen--;
> return std::string(path, buflen);
> }
>
> If you think that's acceptable, I'll submit the patch upstream.
IMO hardcoding the path is the most sensible way for ports.
> pdflatex is used to compile manual, application notes and presentations
> during build; it's part of print/texlive_base, which is a large port; should
> we stay with it or do you have alternatives to suggest?
That's not really a problem. If it needs pdflatex, list the dependency.
