Re: [NEW/WIP] Qflow porting // [2/7] Yosys
On 8/10/2018 8:11 AM, Stuart Henderson wrote: > On 2018/08/10 11:45, Stuart Henderson wrote: >> Save trouble, it's not needed. These config options don't do anything useful. >> Still building but here's a diff on top of your last tar which fixes a few >> little issues (one of which was failure to fetch the tarball from >> MASTER_SITES :) Thanks for being a step ahead of me--that's what I was trying to say :) > Oops, need to honour CXXFLAGS too. Rather than stacking diffs (and most > of the more explanatory parts are in the last one I sent) here's a new > tar. > > If it still works for you I'm happy with importing like this, any OKs to > do so? (or someone can go ahead with my OK). > > Yes, ok. ~Brian
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
On 2018/08/10 11:45, Stuart Henderson wrote: > Save trouble, it's not needed. These config options don't do anything useful. > Still building but here's a diff on top of your last tar which fixes a few > little issues (one of which was failure to fetch the tarball from > MASTER_SITES :) Oops, need to honour CXXFLAGS too. Rather than stacking diffs (and most of the more explanatory parts are in the last one I sent) here's a new tar. If it still works for you I'm happy with importing like this, any OKs to do so? (or someone can go ahead with my OK). yosys,2.tgz Description: Binary data
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
On 2018/08/10 08:41, Alessandro DE LAURENZIS wrote:
> Hi Brian,
>
> On 08/10/18 06:20, Brian Callahan wrote:
> >
> >
> > On 8/10/2018 12:05 AM, Alessandro DE LAURENZIS wrote:
> > > Hi Brian,
> > >
> > > [...]
> > > > Could you explain why ports-gcc is needed? Is there a reason that
> > > > gcc-4.9.4 would be preferred over clang-6.0.0?
> > > > Usually, if you have a COMPILER line, you have a comment above it
> > > > with a reason why. I don't know if it's true for this port, but
> > > > something like:
> > > > # C++11
> > > > COMPILER = base-clang ports-gcc
> > > >
> > > > is usually what is wanted here.
> > >
> > > Actually, when compiled with base-clang, I was observing some
> > > segmentation faults during tests (the first in test/fsm no. 43).
> > >
> > > After the upgrade to a more recent snapshot (I'm currently using the
> > > one dated 4th Aug), the test suite completes without errors even using
> > > clang. So, I agree with your suggestion.
> > >
> >
> > Regardless, if you have a COMPILER line, you should leave a comment
> > saying why. There's no way someone would know there were problems unless
> > you tell us.
> >
> > > Please also note that we need a pre-build "conditional", since the
> > > "config-" target in upstream Makefile is different for clang
> > > (config-clang) and gcc (config-gcc-4.8); I defined the variable
> > > CONFIG_TARGET and set it after the ".include ", according
> > > to the value of CHOSEN_COMPILER:
> > >
> > > [... snip ...]
> > > pre-build:
> > > ${SUBST_CMD} ${WRKSRC}/kernel/yosys.cc
> > > @cd ${WRKBUILD} && exec ${MAKE_PROGRAM} config-$(CONFIG_TARGET)
> > >
> > > [...]
> > >
> > > .include
> > >
> > > .if ${CHOSEN_COMPILER} == "base-clang"
> > > CONFIG_TARGET = clang
> > > .else
> > > CONFIG_TARGET = gcc-4.8
> > > .endif
> > > [... snip ...]
> > >
> > > Please confirm that this is acceptable (or suggest any wiser
> > > alternatives).
> > >
> >
> > It's late, so I'll have to revisit this bit in the morning, but there
> > are examples where we simply just pick one single config target (I think
> > in my stuff I always pick clang and massage it to also work with gcc).
> > I'll find you a more concrete example of this tomorrow.
> >
> > >
> > > [...]
> > > > Some other notes:
> > > >
> > > > As I understand Makefile.template, you should prefer the GH_*
> > > > variables for this port, since everything is auto-generated anyway.
> > > > It will also let you get rid of your VERSION variable, since the GH_*
> > > > variables will take care of it.
> > >
> > > I was following the comment in Makefile.template:
> > >
> > > [... snip ...]
> > > #
> > > # github:
> > > # /releases/ -> preferred. ignore GH_*, just use MASTER_SITES and
> > > DISTNAME.
> > > # /archive/ -> GH_ACCOUNT and GH_PROJECT, plus either GH_TAGNAME or
> > > GH_COMMIT.
> > > #
> > > [... snip ...]
> > >
> > > (in this case we have a release). I see a bunch of other ports doing
> > > similar things (e.g., games/minetest, textproc/py-rdflib, ...).
> > >
> >
> > Huh? You don't have a release. Your MASTER_SITES line clearly has
> > /archive/ in it. Github is needlessly confusing, and it is possible that
> > comment could be worded better because I can see where the confusion
> > comes from.
> >
> > > Should I use GH_TAGNAME instead?
> > >
> >
> > In this case, yes.
>
> Got it. Please see the attached tarball.
>
> Waiting for your further feedback.
>
> >
> > > > Your LDFLAGS line might be better located as a part of your
> > > > MAKE_FLAGS line.
> > >
> > > Done.
> > >
> > > Updated tarball enclosed.
> > >
> >
> > Thanks. I'll take a closer look at this tomorrow. But at a quick glance,
> > if we decide to keep it, that conditional at the very bottom is going to
> > have to be pulled up above pre-build.
>
> I'm not a make expert at all, but it seems I can't:
>
> [... snip ...]
> *** Parse error in /usr/ports/mystuff/cad/yosys: Malformed conditional
> (${CHOSEN_COMPILER} == "base-clang") (Makefile:54)
> *** Parse error: Need an operator in '"base-clang"' (Makefile:54)
> [... snip ...]
>
> I found x11/vlc where a similar conditional is done after the .include
Save trouble, it's not needed. These config options don't do anything useful.
Still building but here's a diff on top of your last tar which fixes a few
little issues (one of which was failure to fetch the tarball from MASTER_SITES
:)
diff --git a/Makefile b/Makefile
index 06e33f6..e596518 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,12 @@
# $OpenBSD$
COMMENT = framework for Verilog RTL synthesis
+
+GH_ACCOUNT = YosysHQ
+GH_PROJECT = yosys
+GH_TAGNAME = yosys-0.7
+DISTNAME = ${GH_TAGNAME}
+
CATEGORIES = cad
HOMEPAGE = http://www.clifford.at/yosys/
@@ -9,35 +15,30 @@ MAINTAINER = Alessandro De Laurenzis
# ISC (yosys), MIT (MiniSat)
PERMIT_PACKAGE_CDROM = Yes
-WANTLIB += ${COMPILER_LIBCXX} c curses m readline tcl85 ffi
-
-GH_ACCOUNT = YosysHQ
-GH_PROJECT = yosys
-GH_TAGNA
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
Hi Brian,
On 08/10/18 06:20, Brian Callahan wrote:
On 8/10/2018 12:05 AM, Alessandro DE LAURENZIS wrote:
Hi Brian,
[...]
Could you explain why ports-gcc is needed? Is there a reason that
gcc-4.9.4 would be preferred over clang-6.0.0?
Usually, if you have a COMPILER line, you have a comment above it
with a reason why. I don't know if it's true for this port, but
something like:
# C++11
COMPILER = base-clang ports-gcc
is usually what is wanted here.
Actually, when compiled with base-clang, I was observing some
segmentation faults during tests (the first in test/fsm no. 43).
After the upgrade to a more recent snapshot (I'm currently using the
one dated 4th Aug), the test suite completes without errors even using
clang. So, I agree with your suggestion.
Regardless, if you have a COMPILER line, you should leave a comment
saying why. There's no way someone would know there were problems unless
you tell us.
Please also note that we need a pre-build "conditional", since the
"config-" target in upstream Makefile is different for clang
(config-clang) and gcc (config-gcc-4.8); I defined the variable
CONFIG_TARGET and set it after the ".include ", according
to the value of CHOSEN_COMPILER:
[... snip ...]
pre-build:
${SUBST_CMD} ${WRKSRC}/kernel/yosys.cc
@cd ${WRKBUILD} && exec ${MAKE_PROGRAM} config-$(CONFIG_TARGET)
[...]
.include
.if ${CHOSEN_COMPILER} == "base-clang"
CONFIG_TARGET = clang
.else
CONFIG_TARGET = gcc-4.8
.endif
[... snip ...]
Please confirm that this is acceptable (or suggest any wiser
alternatives).
It's late, so I'll have to revisit this bit in the morning, but there
are examples where we simply just pick one single config target (I think
in my stuff I always pick clang and massage it to also work with gcc).
I'll find you a more concrete example of this tomorrow.
[...]
Some other notes:
As I understand Makefile.template, you should prefer the GH_*
variables for this port, since everything is auto-generated anyway.
It will also let you get rid of your VERSION variable, since the GH_*
variables will take care of it.
I was following the comment in Makefile.template:
[... snip ...]
#
# github:
# /releases/ -> preferred. ignore GH_*, just use MASTER_SITES and
DISTNAME.
# /archive/ -> GH_ACCOUNT and GH_PROJECT, plus either GH_TAGNAME or
GH_COMMIT.
#
[... snip ...]
(in this case we have a release). I see a bunch of other ports doing
similar things (e.g., games/minetest, textproc/py-rdflib, ...).
Huh? You don't have a release. Your MASTER_SITES line clearly has
/archive/ in it. Github is needlessly confusing, and it is possible that
comment could be worded better because I can see where the confusion
comes from.
Should I use GH_TAGNAME instead?
In this case, yes.
Got it. Please see the attached tarball.
Waiting for your further feedback.
Your LDFLAGS line might be better located as a part of your
MAKE_FLAGS line.
Done.
Updated tarball enclosed.
Thanks. I'll take a closer look at this tomorrow. But at a quick glance,
if we decide to keep it, that conditional at the very bottom is going to
have to be pulled up above pre-build.
I'm not a make expert at all, but it seems I can't:
[... snip ...]
*** Parse error in /usr/ports/mystuff/cad/yosys: Malformed conditional
(${CHOSEN_COMPILER} == "base-clang") (Makefile:54)
*** Parse error: Need an operator in '"base-clang"' (Makefile:54)
[... snip ...]
I found x11/vlc where a similar conditional is done after the .include
--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis
yosys.tar.gz
Description: application/gzip
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
On 8/10/2018 12:05 AM, Alessandro DE LAURENZIS wrote:
> Hi Brian,
>
> [...]
>> Could you explain why ports-gcc is needed? Is there a reason that
>> gcc-4.9.4 would be preferred over clang-6.0.0?
>> Usually, if you have a COMPILER line, you have a comment above it
>> with a reason why. I don't know if it's true for this port, but
>> something like:
>> # C++11
>> COMPILER = base-clang ports-gcc
>>
>> is usually what is wanted here.
>
> Actually, when compiled with base-clang, I was observing some
> segmentation faults during tests (the first in test/fsm no. 43).
>
> After the upgrade to a more recent snapshot (I'm currently using the
> one dated 4th Aug), the test suite completes without errors even using
> clang. So, I agree with your suggestion.
>
Regardless, if you have a COMPILER line, you should leave a comment
saying why. There's no way someone would know there were problems unless
you tell us.
> Please also note that we need a pre-build "conditional", since the
> "config-" target in upstream Makefile is different for clang
> (config-clang) and gcc (config-gcc-4.8); I defined the variable
> CONFIG_TARGET and set it after the ".include ", according
> to the value of CHOSEN_COMPILER:
>
> [... snip ...]
> pre-build:
> ${SUBST_CMD} ${WRKSRC}/kernel/yosys.cc
> @cd ${WRKBUILD} && exec ${MAKE_PROGRAM} config-$(CONFIG_TARGET)
>
> [...]
>
> .include
>
> .if ${CHOSEN_COMPILER} == "base-clang"
> CONFIG_TARGET = clang
> .else
> CONFIG_TARGET = gcc-4.8
> .endif
> [... snip ...]
>
> Please confirm that this is acceptable (or suggest any wiser
> alternatives).
>
It's late, so I'll have to revisit this bit in the morning, but there
are examples where we simply just pick one single config target (I think
in my stuff I always pick clang and massage it to also work with gcc).
I'll find you a more concrete example of this tomorrow.
>
> [...]
>> Some other notes:
>>
>> As I understand Makefile.template, you should prefer the GH_*
>> variables for this port, since everything is auto-generated anyway.
>> It will also let you get rid of your VERSION variable, since the GH_*
>> variables will take care of it.
>
> I was following the comment in Makefile.template:
>
> [... snip ...]
> #
> # github:
> # /releases/ -> preferred. ignore GH_*, just use MASTER_SITES and
> DISTNAME.
> # /archive/ -> GH_ACCOUNT and GH_PROJECT, plus either GH_TAGNAME or
> GH_COMMIT.
> #
> [... snip ...]
>
> (in this case we have a release). I see a bunch of other ports doing
> similar things (e.g., games/minetest, textproc/py-rdflib, ...).
>
Huh? You don't have a release. Your MASTER_SITES line clearly has
/archive/ in it. Github is needlessly confusing, and it is possible that
comment could be worded better because I can see where the confusion
comes from.
> Should I use GH_TAGNAME instead?
>
In this case, yes.
>> Your LDFLAGS line might be better located as a part of your
>> MAKE_FLAGS line.
>
> Done.
>
> Updated tarball enclosed.
>
Thanks. I'll take a closer look at this tomorrow. But at a quick glance,
if we decide to keep it, that conditional at the very bottom is going to
have to be pulled up above pre-build.
~Brian
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
Hi Brian,
[...]
Could you explain why ports-gcc is needed? Is there a reason that
gcc-4.9.4 would be preferred over clang-6.0.0?
Usually, if you have a COMPILER line, you have a comment above it with a
reason why. I don't know if it's true for this port, but something like:
# C++11
COMPILER = base-clang ports-gcc
is usually what is wanted here.
Actually, when compiled with base-clang, I was observing some
segmentation faults during tests (the first in test/fsm no. 43).
After the upgrade to a more recent snapshot (I'm currently using the one
dated 4th Aug), the test suite completes without errors even using
clang. So, I agree with your suggestion.
Please also note that we need a pre-build "conditional", since the
"config-" target in upstream Makefile is different for clang
(config-clang) and gcc (config-gcc-4.8); I defined the variable
CONFIG_TARGET and set it after the ".include ", according
to the value of CHOSEN_COMPILER:
[... snip ...]
pre-build:
${SUBST_CMD} ${WRKSRC}/kernel/yosys.cc
@cd ${WRKBUILD} && exec ${MAKE_PROGRAM} config-$(CONFIG_TARGET)
[...]
.include
.if ${CHOSEN_COMPILER} == "base-clang"
CONFIG_TARGET = clang
.else
CONFIG_TARGET = gcc-4.8
.endif
[... snip ...]
Please confirm that this is acceptable (or suggest any wiser alternatives).
[...]
Some other notes:
As I understand Makefile.template, you should prefer the GH_* variables
for this port, since everything is auto-generated anyway. It will also
let you get rid of your VERSION variable, since the GH_* variables will
take care of it.
I was following the comment in Makefile.template:
[... snip ...]
#
# github:
# /releases/ -> preferred. ignore GH_*, just use MASTER_SITES and DISTNAME.
# /archive/ -> GH_ACCOUNT and GH_PROJECT, plus either GH_TAGNAME or
GH_COMMIT.
#
[... snip ...]
(in this case we have a release). I see a bunch of other ports doing
similar things (e.g., games/minetest, textproc/py-rdflib, ...).
Should I use GH_TAGNAME instead?
Your LDFLAGS line might be better located as a part of your MAKE_FLAGS
line.
Done.
Updated tarball enclosed.
--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis
yosys.tar.gz
Description: application/gzip
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
Hi Alessandro --
On 8/4/18 3:04 AM, Alessandro DE LAURENZIS wrote:
Hi Stuart,
On 08/03/18 17:56, Alessandro DE LAURENZIS wrote:
Hi Stuart,
On 08/03/18 13:21, Stuart Henderson wrote:
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}"
Fixed
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.
Added it in post-install target:
post-install:
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py \
${PREFIX}/share/yosys/python3
- compiler name forced to eg++;
Don't hardcode this, use MAKE_FLAGS= CXX="${CXX}" etc.
Fixed
Could you explain why ports-gcc is needed? Is there a reason that
gcc-4.9.4 would be preferred over clang-6.0.0?
Usually, if you have a COMPILER line, you have a comment above it with a
reason why. I don't know if it's true for this port, but something like:
# C++11
COMPILER = base-clang ports-gcc
is usually what is wanted here.
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.
As discussed (thanks for your explanation), I patched to use
${PREFIX} and then added:
pre-build:
${SUBST_CMD} ${WRKSRC}/kernel/yosys.cc
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.
>> 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.
Actually I noticed that the corresponding target isn't run by
default. Should I force it? I mean, is the extra documentation
normally installed in other ports?
New tarball attached.
There is a local copy of MiniSat in ./libs, so I tweaked a bit the
license markers:
# ISC (yosys), MIT (MiniSat)
New tarball attached.
Some other notes:
As I understand Makefile.template, you should prefer the GH_* variables
for this port, since everything is auto-generated anyway. It will also
let you get rid of your VERSION variable, since the GH_* variables will
take care of it.
Your LDFLAGS line might be better located as a part of your MAKE_FLAGS line.
That's all for now from a quick read; I'll try to test it later today.
~Brian
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
Hi Stuart,
On 08/03/18 17:56, Alessandro DE LAURENZIS wrote:
Hi Stuart,
On 08/03/18 13:21, Stuart Henderson wrote:
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}"
Fixed
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.
Added it in post-install target:
post-install:
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py \
${PREFIX}/share/yosys/python3
- compiler name forced to eg++;
Don't hardcode this, use MAKE_FLAGS= CXX="${CXX}" etc.
Fixed
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.
As discussed (thanks for your explanation), I patched to use ${PREFIX}
and then added:
pre-build:
${SUBST_CMD} ${WRKSRC}/kernel/yosys.cc
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.
>> 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.
Actually I noticed that the corresponding target isn't run by default.
Should I force it? I mean, is the extra documentation normally installed
in other ports?
New tarball attached.
There is a local copy of MiniSat in ./libs, so I tweaked a bit the
license markers:
# ISC (yosys), MIT (MiniSat)
New tarball attached.
--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis
yosys.tar.gz
Description: application/gzip
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
Hi Stuart,
On 08/03/18 13:21, Stuart Henderson wrote:
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}"
Fixed
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.
Added it in post-install target:
post-install:
${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py \
${PREFIX}/share/yosys/python3
- compiler name forced to eg++;
Don't hardcode this, use MAKE_FLAGS= CXX="${CXX}" etc.
Fixed
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.
As discussed (thanks for your explanation), I patched to use ${PREFIX}
and then added:
pre-build:
${SUBST_CMD} ${WRKSRC}/kernel/yosys.cc
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.
>> 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.
Actually I noticed that the corresponding target isn't run by default.
Should I force it? I mean, is the extra documentation normally installed
in other ports?
New tarball attached.
--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis
yosys.tar.gz
Description: application/gzip
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
On 2018/08/03 13:57, Alessandro DE LAURENZIS wrote:
> Hi Stuart,
>
> On 08/03/18 13:21, Stuart Henderson wrote:
> > > 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.
> >
>
> Do you mean something like this?
>
> std::string proc_self_dirname()
> {
> return "/usr/local/bin/";
> }
>
> How does it play with a different $LOCALBASE?
>
> --
> Alessandro DE LAURENZIS
> [mailto:jus...@atlantide.t28.net]
> Web: http://www.atlantide.t28.net
> LinkedIn: http://it.linkedin.com/in/delaurenzis
>
Either patch to use ${PREFIX} and use ${SUBST_CMD} on the file
after patching, or use /usr/local and "sed -i s,/usr/local,${PREFIX},"
(PREFIX relates to "where this port installs", LOCALBASE relates to
"where other ports on the system are found").
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
Hi Stuart,
On 08/03/18 13:21, Stuart Henderson wrote:
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.
Do you mean something like this?
std::string proc_self_dirname()
{
return "/usr/local/bin/";
}
How does it play with a different $LOCALBASE?
--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: [NEW/WIP] Qflow porting // [2/7] Yosys
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.
[NEW/WIP] Qflow porting // [2/7] Yosys
Dear ports@ readers,
Yosys [1] is the second port required by Qflow [2]:
From DESCR:
[... snip ...]
Yosys Open SYnthesis Suite
Yosys is a framework for Verilog RTL synthesis. It currently has
extensive Verilog-2005 support and provides a basic set of synthesis
algorithms for various application domains. Selected features and
typical applications:
- Process almost any synthesizable Verilog-2005 design
- Converting Verilog to BLIF / EDIF/ BTOR / SMT-LIB / simple RTL Verilog
- Built-in formal methods for checking properties and equivalence
- Mapping to ASIC standard cell libraries (in Liberty File Format)
- Mapping to Xilinx 7-Series and Lattice iCE40 FPGAs
- Foundation and/or front-end for custom flows
Yosys can be adapted to perform any synthesis job by combining the
existing passes (algorithms) using synthesis scripts and adding
additional passes as needed by extending the Yosys C++ code base.
[... snip ...]
It requires abc [3] to run (porting still under discussion).
Some highlights follow.
It doesn't compile at all using base-gcc; with base-clang, compile phase
reaches the end, but I see a couple of segmentation faults during
regression tests (should I investigate deeper?). With ports-gcc, it
compiles and runs as expected.
I think we need the line:
FAKE_FLAGS =PREFIX="${LOCALBASE}"
since PREFIX is explicitly set to /usr/local in upstream Makefile when
undefined.
Also, in order to avoid python3 setup errors, I needed to set
CONFIGURE_STYLE = none
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...)
Patches
===
Makefile requires minimal adjustments:
- PRETTY = 0 for verbose logging during build;
- -ggdb removed;
- compiler name forced to eg++;
- added -lcurses and removed -lrt and -ldl from LDLIBS;
Test suite scripts' shebangs are wrong (#!/bin/bash), but actually they
are all called as arguments of test/tools/autotest.sh, so I patched only
the latter.
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.
Dependencies
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?
abc is required for both running some yosys' commands and to complete
regression tests.
I would love to switch from bash to sh in all scripts, but this requires
time and I think it would be better to involve the author, so for the
moment I would accept the dependency.
Tarball attached.
[1] http://www.clifford.at/yosys/
[2] https://marc.info/?l=openbsd-ports&m=153270090320035&w=2
[3] https://marc.info/?l=openbsd-ports&m=153270072519966&w=2
--
Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
Web: http://www.atlantide.t28.net
LinkedIn: http://it.linkedin.com/in/delaurenzis
yosys.tar.gz
Description: application/gzip
