Apologies for the unclear explanation. I have experience writing non-trivial shell scripts and would like to help improving make/build_*.sh if possible. However, any changes I make are likely to be naïve and break someone's use case.
Before bothering jsource with potential patches, I would ideally like to run some test suite against the build process, ensuring my changes don't things. Is this currently possible? What is the *right* process to go about sharing build system changes upstream? bill lam <bbill....@gmail.com> wrote: > Sorry I don't quite understand your question, nevertheless it is > up to you inside your own fork because this is open-source, > please feel free to improve it. > > Eric or Chris should be the best person to anwser because they > build official binaries using the make folder. > > Fri, 24 Jan 2020, JSource написал(а): > > 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 <bbill....@gmail.com> 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 > > > <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? > > > > > > > > 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 > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
