The build system is very idiosyncratic. I am the primary user of folder make. Except perhaps for an unknown number of users who struggled to understand it an fit it to their needs.
I use the make folder only to build official releases and there the targets are limited and we have complete control over variables such as which compiler to use. Bill has improved things with make2 to address his wider concerns such as android pi etc. I should probably at least move to using make2 but the days are too short and my schedule to busy to take on a project to fix something that for my use isn't broken. Not sure how to get this cleaned up so that it is unified, streamlined and makes you happy, keeps Bill happy, and causes me zero grief. If you made a make3 that Bill was willing to use and agreed was an improvement on make2, then I can promise that I will give it a shot for building official releases and adopt it if not too much trouble. In terms of testing make3: if it is easy to use to build binaries for clang 64bit windows/linux/mac and android/pi and they all pass the test suite, then you are pretty close. On Fri, Jan 24, 2020 at 1:53 AM ethiejiesa via Source <[email protected]> wrote: > 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 <[email protected]> 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 <[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 > > > > -- > > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
