Envoyé de mon iPhone
Thanks for the comments! Mine are below:
Please will you remove the first build of GNUstep Make. Neither libdispatch nor libobjc2 need GNUstep Make (in the case of libobjc2, intentionally to avoid a circular dependency).
If -Make is not installed, then libobjc2 will install as a normal library, just set the prefix to whatever you want (it defaults to /usr/local, you probably want /usr on Ubuntu).
I did see a previous post on the list here about that. But I could not get it to work. I could not get further builds of GNUstep to properly build and use either /usr or /usr/local when libobjc2 was installed there.
If you have any suggestions as to the correct flags to get it to work, I’d be happy to try again.
My two cents here : I've played this morning to adapt the script to pure Debian Jessie. It worked almost as is with only two dependencies whose names were different. Then I tried to remove the first gnu step-make compilation from your script and it failed at base's configure stage. It complained about the objc compiler. It was Essentially because /usr/local/lib isn't in LD_LIBRARY_PATH on debian.I then installed libobjc in /usr instead of /usr/local and everything works.
Bertrand Ubuntu 16.04 includes clang 3.8 (clang-3.8 package), which is ample for compiling modern Objective-C code (and, for the next couple of weeks, is the latest release), so it’s probably more sensible to install that than to build from source. Even better, they’ve now fixed the idiocy from Ubuntu 14.04 where you then had to force-deinstall a bunch of gcc packages that they made the clang package depend on to get a working compiler.
Which I do. Maybe you were looking at the 14.04 & 15.04 scripts which I didn’t change? You will need to update the [OBJ]C[XX]FLAGS everywhere because now clang / clang++ are called clang-3.8 and clang++-3.8.
Do I? Everything seemed to work fine with the repository installed version without doing that. I don’t know why you think you need '-DCMAKE_ASM_FLAGS=-c’ in the libobjc2 build. I just tried cmake -G Ninja -DCMAKE_C_COMPILER=clang-3.8 -DCMAKE_CXX_COMPILER=clang++-3.8 on Ubuntu 16.04 and it seemed to work.
It’s also probably not a good idea to pass -DTESTS=OFF - it only takes a few extra seconds on a moderately modern machine to build and run the tests and you get a bit of sanity checking early on from doing so.
If you think they aren’t needed, I can try with out them.
Please don’t use -fobjc-nonfragile-abi, it’s been deprecated for years. The correct flag is -fobjc-runtime=gnustep-1.8.
Interesting. I didn’t see that anywhere. Will have to update this page to note:
I will correct it. In theory, the libdispatch0 package from Ubuntu ought to work, though I’ve not tested it
I believe I tested it and it didn’t work. But right now I can’t recall what I ran into. This line:
source ~/.bashrc
Is probably dangerous. You’re already sourcing GNUstep.sh earlier and you may end up with something very confusing, as many people have .bashrc scripts that don’t expect to be sourced more than once in a shell. Similarly, the advice at the end is bad and you should tell people to source GNUstep.[c]sh, not re-source their .bashrc into a shell that’s already loaded it (or into a shell that may not understand it if bash is not their current shell).
Hmm good point. I added that line because for some reason building the apps would give me errors without it. It grabbed the idea from the old script, and it did work for me- but it was a fresh install. And I originally tried without that advice at the end, but I still got errors trying to build test apps. Maybe better advice would be to close and re-open the terminal. The script would be a lot more readable if this were in a function, not copied and pasted a dozen times:
if [ "$PROMPT" = true ] ; then
echo -e "\n\n"
read -p "${GREEN}Press enter to continue...${NC}”
I agree- I thought about it before I uploaded it. But I wanted to get it out for critiquing and figured I’d change it when I’d make other changes.
Back to building new VMs for testing! Haha.
|