ethiejiesa via Source <sou...@jsoftware.com> wrote:
> Okay, thank you.
>
> When first going about packaging J, I do recall reading overview.txt. At least
> at that time, it was entirely unclear to me how to judge the differences
> between the two, as it just menions that make it is "somewhat simpler." Is
> there a particular objective behind maintaining the two build pipelines, or is
> it mainly due to legacy reasons?
Typo. Rather, *make2* is "somewhat simpler."
> If it would be of any use, I would not mind writing up my experience trying to
> package J as a complete newcomer. There were several surprises that I never
> found documented in the repo nor the wiki, and the J repository looks quite
> idiosyncratic compared to "typical" software one tries to package for a linux
> distro.
>
> bill lam <bbill....@gmail.com> wrote:
>
> > users can choose the one that they prefer as mentioned inside overview.txt
> >
> > cc --ver does not work in some platforms or gcc/clang version in that they
> > print something else that identifying them as gcc/clang.
> >
> > On Wed, Jan 22, 2020, 2:48 PM ethiejiesa via Source <sou...@jsoftware.com>
> > wrote:
> >
> > > That worked beautifully. Thank you for the pointer.
> > > Did I miss some obvious documentation about building jsource? I am curious
> > > about the need for both make and make2.
> > >
> > > bill lam <bbill....@gmail.com> wrote:
> > >
> > > > I suggest you to use make file under make2, see the readme there. It
> > > > uses
> > > > readlink to get the real filename of cc.
> > > >
> > > > On Tue, Jan 21, 2020, 1:05 PM ethiejiesa via Source <
> > > sou...@jsoftware.com>
> > > > wrote:
> > > >
> > > > > > If you use either gcc or clang, you can export $CC before make.
> > > > >
> > > > > Taking `build_libj.sh` for example, the problem is that it only
> > > > > detects
> > > > > gcc in
> > > > > cases where CC contains "gcc" as a substring. This breaks when, for
> > > > > example,
> > > > > CC=cc and cc is a symlink to some gcc. For example, when building for
> > > > > a
> > > > > non-native target, one usually sets up cc to point to the appropriate
> > > build
> > > > > toolchain, e.g. /usr/bin/arm-linux-gnueabihf-gcc.
> > > > >
> > > > > Interestingly, `build_jconsole.sh` adopts a diffrent, stronger
> > > assumption
> > > > > that
> > > > > CC=gcc when gcc is the compiler. Note that clang compilation mostly
> > > Just
> > > > > Works
> > > > > TM, since the scripts assume clang by default.
> > > > >
> > > > > > j forum discards attachment so we can't see your patch.
> > > > >
> > > > > Oops. Thank you for pointing this out. Including both patches in the
> > > body
> > > > > is
> > > > > probably too much clutter, so for illustrative purposes, I will simply
> > > > > post the
> > > > > smaller one below:
> > > > >
> > > > >
> > > > > --- make/build_jconsole.sh 2019-12-17 18:25:11.713700768 +0900
> > > > > +++ make/build_jconsole.sh 2019-12-17 18:26:45.090341029 +0900
> > > > > @@ -5,6 +5,7 @@
> > > > > cd ~
> > > > >
> > > > > macmin="-mmacosx-version-min=10.6"
> > > > > +ccver=$(${CC} --version)
> > > > > USE_LINENOISE="${USE_LINENOISE:=1}"
> > > > >
> > > > > if [ "x$CC" = x'' ] ; then
> > > > > @@ -20,7 +21,7 @@
> > > > > export CC
> > > > > fi
> > > > >
> > > > > -if [ $CC = "gcc" ] ; then
> > > > > +if [ -z "${ccver##*(GCC)*}" ]; then
> > > > > # gcc
> > > > > common=" -fPIC -O1 -fwrapv -fno-strict-aliasing -Wextra
> > > > > -Wno-maybe-uninitialized -Wno-unused-parameter -Wno-sign-compare
> > > > > -Wno-clobbered -Wno-empty-body -Wno-unused-value -Wno-pointer-sign
> > > > > -Wno-parentheses"
> > > > > OVER_GCC_VER6=$(echo `$CC -dumpversion | cut -f1 -d.` \>= 6 | bc)
> > > > >
> > > > >
> > > > > Using the above, and a similar one for `build_libj.sh`, I have
> > > successfully
> > > > > compiled for aarch64 and x86 musl-based toolchains.
> > > > >
> > > > > bill lam <bbill....@gmail.com> wrote:
> > > > >
> > > > > > j forum discards attachment so we can't see your patch.
> > > > > >
> > > > > > If you use either gcc or clang, you can export $CC before make.
> > > > > >
> > > > > > FWIW, I have no problem in cross compiling Windows binary with mingw
> > > on
> > > > > > linux using make2.
> > > > > >
> > > > > > On Tue, Jan 21, 2020, 10:36 AM ethiejiesa via Source <
> > > > > sou...@jsoftware.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello Source,
> > > > > > >
> > > > > > > Support for cross-compilation is broken by assumptions made in
> > > > > > > `make/build_jconsole.sh` and `make/build_libj.sh`. Is there a
> > > > > reasonable
> > > > > > > fix?
> > > > > > > I attach some naïve patches that work for my personal (linux) use
> > > case.
> > > > > > >
> > > > > > > I am the maintainer of the J package for Void Linux. The
> > > distribution
> > > > > > > offers
> > > > > > > binary package downloads for several target platforms by
> > > > > cross-compiling
> > > > > > > packages on a build farm. In order to support their build
> > > toolchains, I
> > > > > > > have to
> > > > > > > patch `make/build_{jconsole,libj}.sh`.
> > > > > > >
> > > > > > > In particular, the problem is that the scripts attempt *ad hoc*
> > > > > detection
> > > > > > > of
> > > > > > > gcc via path parsing, and cross-compilation toolchains break those
> > > > > > > assumptions.
> > > > > > > This can be worked around by instead parsing the output of `$CC
> > > > > --version`.
> > > > > > > Please see the attached patches against J901-d for a concrete
> > > example.
> > > > > > >
> > > > > > > On a larger note, however, the above fix is still a fragile hack.
> > > > > Ideally,
> > > > > > > we
> > > > > > > want to be completely compiler agnostic without directly checking
> > > > > compiler
> > > > > > > and
> > > > > > > version information. The current state of affairs seems to be
> > > simply
> > > > > > > setting
> > > > > > > compiler flags (for reasons I do not grok yet); however, perhaps
> > > > > > > we
> > > > > could
> > > > > > > move
> > > > > > > the necessary flags into equivalent `#pragma` statements or
> > > something
> > > > > > > similar?
> > > > > > >
> > > > > > > I am out of my depth here, so I mostly intend this email as a mean
> > > of
> > > > > > > instigating discussion.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > BW
> > > > > > >
> > > ----------------------------------------------------------------------
> > > > > > > For information about J forums see
> > > http://www.jsoftware.com/forums.htm
> > > > > > >
> > > > > >
> > > ----------------------------------------------------------------------
> > > > > > For information about J forums see
> > > http://www.jsoftware.com/forums.htm
> > > > > ----------------------------------------------------------------------
> > > > > For information about J forums see http://www.jsoftware.com/forums.htm
> > > > >
> > > > ----------------------------------------------------------------------
> > > > For information about J forums see http://www.jsoftware.com/forums.htm
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > >
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
