Thank you for the perspicuous explanation and concrete direction forward. Eric Iverson <[email protected]> wrote:
> 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
