make folder is the original and used for building official release. It requires users to READ instructions in order to set up and go. But too many users don't like to read and follow instructions, they just expect to type configure then make to do everything. To life easier, there comes make2, users need only to build_all.sh right after cloning the repos.
On Fri, Jan 24, 2020, 12:04 PM ethiejiesa via Source <[email protected]> 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? > > 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 <[email protected]> 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 < > [email protected]> > > 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 <[email protected]> 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 < > > > [email protected]> > > > > 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 <[email protected]> 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 < > > > > > [email protected]> > > > > > > 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
