Okay, so make2 exists as a simple conveniece. And this presumably at the cost of (cross-platform) build flexibility?
Instead of continuing a barrage of micro-questions, permit me to directly share my intent. I would like to improve the build scripts in make; however, this seems like a Chesterton's fence [0] problem. Is there a way for users to test changes to the build system? [0]:https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence bill lam <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
