Added autotools support for configuration, cross-compilation and installation.

[nihilus]

Added autotools support for configuration, cross-compilation and installation; now we also build ldd from uClibc so we have a tool on OS X for inspecting files.

[endrazine]

Hi Markus,

This is an epic commit, thanks !

I'm trying to build your branch and would need your help. I can fetch the code without issue:

jonathan@blackbox:/tmp/toto/wcc$ git pull && git submodule init && git submodule update 
Already up-to-date.
jonathan@blackbox:/tmp/toto/wcc$ 

Now let's try to build using the new autotools :)

jonathan@blackbox:/tmp/toto/wcc$ ./autogen.sh && ./configure                                                                                              
...
configure: error: Unable to find the capstone.h header!
jonathan@blackbox:/tmp/toto/wcc$ 

Ok, I figured out I needed to specify the capstone include path as below:

jonathan@blackbox:/tmp/toto/wcc$ ./configure --with-capstone-incdir=/usr/include/capstone/                                                
checking build system type... x86_64-pc-linux-gnu
...checking for libiberty.h... no
configure: error: Unable to find the libiberty.h header!
jonathan@blackbox:/tmp/toto/wcc$ 

We now need to specify the libiberty path to the configure script too:

jonathan@blackbox:/tmp/toto/wcc$ ./configure --with-capstone-incdir=/usr/include/capstone/ --with-libiberty-incdir=/usr/include/libiberty/
...
checking for openlibm.h... no
configure: error: Unable to find the openlibm.h header!
jonathan@blackbox:/tmp/toto/wcc$ 

The configure script also needs the patch of openlibm.h. The problem here is that with your commit, this submodule is no longer fetched:

jonathan@blackbox:/tmp/toto/wcc$ cat .gitmodules 
[submodule "doc/wikidocs"]
    path = doc/wikidocs
    url = https://github.com/endrazine/wcc.wiki.git
jonathan@blackbox:/tmp/toto/wcc$ 

As such, we have nowhere to point to:

jonathan@blackbox:/tmp/toto/wcc$ find . |grep openlib -i
jonathan@blackbox:/tmp/toto/wcc$ 

Am I missing something obvious here ? If not, would you fix please help this problem before we merge ? :)

Thanks again, it seems like great work ! I need to dive a bit into it once I get it to build tbh.

j-

[nihilus]

I did remove the submodules and left it up to the user to provide the correct paths in the configure script instead... Is that a problem? As for openlibm the configure script should be improved to detect if the target archtietecure is x86-64 or not to detect if it is needed.

[endrazine]

Hi Nihilus,

I did remove the submodules and left it up to the user to provide the correct paths in the configure script instead... Is that a problem?

I'm usure I see why : you have a use case to use different submodules ? :)

Even after fetching the relevant openlibm codebase, I face an issue in including the correct openlibm include directory:

jonathan@blackbox:/tmp/toto/wcc$ ./configure --with-capstone-incdir=/usr/include/capstone/ --with-libiberty-incdir=/usr/include/libiberty/ --with-openlibm-incdir=./src/wsh/openlibm/include/
...
checking openlibm.h presence... no
checking for openlibm.h... no
configure: error: Unable to find the openlibm.h header!
jonathan@blackbox:/tmp/toto/wcc$ 

Cheers,

j-

[nihilus]

Usually I fetch relevant packages with the OS' package manager when building something.

I can fix so the configure scripts check out submodules and link against them if that is the desired behaviour.

It will have to wait until tomorrow however since I am away over the easter holidays.

[nihilus]

One question before redoing some building of wsh with autoconf: is openlibm required for all 64-bits system (e.g. AArch64) or only for x86-64?

[nihilus]

OK, now I've re-added the lua 5.3.2 files and integrated them in autotools for building an linking against them. And I did rewrote and licensed wldd under the MIT license.

[nihilus]

That one should be deleted for sure... Git keeps adding things back.

[nihilus]

So I guess I should try to get things "squashed", right? However I failed terrible when trying to.

[endrazine]

Hi Nihilus :)

First, thanks a lot for this commit : it's a lot of work and I'm grateful ! I haven't merged it yet because I find a few issues with it I thought we could discuss first :)

1) Moving to autobuild/autotool : very cool, let's do this ! 2) Including GNU ld: Is there really a benefit compared to using the one you can get from your system's toolchain ? WCC is entirely MIT/BSD licensed, I'm not naturally enclined to lose this. 3) I don't understand where we stand now in respect to modules (openlibm is of course a requirement, it seems you took it of entirely. How does this work ? Lua also disappeared at some stage it seems :-/), the build I fetched over last week end didn't build due to multiple missing include files. I'm of course reluctant to merge a commit that breaks the build process. I haven't tried your latest commit yet I must admit. 4) You could clean a bit the hardcoded pathnames before we merge: I found dozens of occurrences of your name and username when grepping the git repo. Let's try to do this before we merge please ? :)

Thanks again for your help mate, this is very cool :)

j-

[endrazine]

One question before redoing some building of wsh with autoconf: is openlibm required for all 64-bits system (e.g. AArch64) or only for x86-64?

It's always needed. I agree we could get libm from the system, but since we link statically, we want a MIT/BSD licensed software. That's why we ship our own :)

[nihilus]

Ah, then I will switch from libm to openlibm even on x86, and readd it to the submodules.

As for GNU ld, it actually means that you specify the path for a linker that is compatible with GNU ld. If using OS X native linker the link-script for x86-64 will break the linking (however lots of other things will break the build process, hence we only build wsh on Linux).

Yeah, I will fix those hardcoded paths...

[nihilus]

The code should now be on par with your master... I've re-added some submodules. As for linenoise.c I've integrated this for a smooth buildprocess.

[rofl0r]

looks like quite a mess to me. if this was my repo, i'd demand that this gets rebased into a handful of clean commits, instead of merging about 100 commits ala "fix previous commit" and even what is imo the epitome of brokenness in a PR: commits merging back the upstream changes.

[nihilus]

Like I wrote before, I did try to squash it. However that failed in a terrible way...

[rofl0r]

if your git-fu is too weak then it's probably best to just start from a clean checkout based on latest master, copy the final version of your changed files over there, and commit that (as a new PR).

[nihilus]

Will do

[wgrr]

@rofl0r i think github now has an option while merging to squash commits, it wouldnt be merged 100 commits.

[rofl0r]

@wgrriffel even if that works, the maintainer can't possibly predict the outcome when clicking on that merge button, and if he doesn't like it, he will have to delete the result and force-push in a hurry, if he wants a clean commit history. but then, looking at the last PR merged by @endrazine, i have the strong feeling that he doesn't care anyway, since the commit was not only technically incorrect, it also had whitespace errors what i both pointed out in the PR, but it was ignored.