Home » Developing U++ » Releasing U++ » Tarball issues
|
|
|
|
|
|
| Re: Tarball issues [message #47380 is a reply to message #47379] |
Tue, 10 January 2017 21:09   |
 |
Klugier
Messages: 1117
Registered: September 2012
Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello amrein,
Quote:
[TODO] - Add to readme and web documentation: gcc should be >= 5.0 (as older versions have problems with C++14 standard).
Our target c++ standard for this release is c++11, not c++14 and GCC versions lesser that 5.0 have got problems with the older one. Currently, only Android Builder supports c++14 by default. When, you will write documentation - please keep this digression in mind.
Sincerely,
Klugier
U++ - one framework to rule them all.
[Updated on: Tue, 10 January 2017 21:13] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: Tarball issues [message #47387 is a reply to message #47384] |
Wed, 11 January 2017 13:01 |
|
Klugier
Messages: 1117
Registered: September 2012
Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello amrein,
While running - "make" command on Ubuntu 16.04 I came across following error:
/bin/sh domake
domake: 14: domake: Bad substitution
Makefile:5: polecenia dla obiektu 'all' nie powiodły się
make: *** [all] Błąd 2
I think the problem is with 14 line of domake script:
When I removed that line I have got one more error:
/bin/sh domake
domake: 36: domake: Syntax error: "(" unexpected
Makefile:5: polecenia dla obiektu 'all' nie powiodły się
Sincerely,
Klugier
U++ - one framework to rule them all.
[Updated on: Wed, 11 January 2017 13:01] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Tarball issues [message #47398 is a reply to message #47395] |
Thu, 12 January 2017 07:47 |
|
|
Hi amrein,
amrein wrote on Wed, 11 January 2017 22:42Question:
- When creating POSIX binary packages, where should I copy the dictionaries (like en-gb.scd and en-us.scd) for theide to pick them?
-> I can't put them in /usr/bin, even if I know that it will work.
-> theide doesn't find them in /usr/share/upp nor does it in /usr/share/upp/scd and I can't figure it out (where does theide search for those files at first start...).
Same problem as with the default GCC.bm... IIRC, I ended up putting it in /usr/share and copying it to $HOME/.upp/theide/ in the install step, which launches when the user first starts TheIDE. The dictionaries will be picked up by TheIDE when placed into the config directory. The unpleasant thing about this is, that it requires makeing this in code in TheIDE itself...
It would by great if U++ or at least TheIDE supported having global configuration in /etc and separate user configs that would overload the global settings. This is kind of standard behavior in posix world... But I think it would be pretty big change.
Best regards,
Honza
|
|
|
|
|
|
| Re: Tarball issues [message #47401 is a reply to message #47394] |
Thu, 12 January 2017 09:10 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi Amrein,
I can confirm a successful build and install from source tarball 10699M using the instructions (make and make install) in readme file on Linux Mint 18.1 (based on Ubuntu). It was a clean install on a machine which did not have even gcc installed. And actually I left gcc out intentionally to test the tarball with clang which worked out of the box just as expected.
Best regards,
Tom
|
|
|
|
| Re: Tarball issues [message #47403 is a reply to message #47401] |
Thu, 12 January 2017 12:27 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi,
Tested on a freshly installed TrueOS (based on FreeBSD).
After installing llvm39 and libnotify, make starts working. Making theide fails but umk gets built.
...
make[1]: don't know how to make ide/app.tpp/Aboutn-us.tppi. Stop
make[1]: stopped in /usr/home/tom/upp-x11-src-10699M/uppsrc
When compiling, strangely, the flags defined in compilation include flagGCC and flagLINUX, while compiling with CLANG on FreeBSD:
...
clang++ -c -x c++ -O3 -ffunction-sections -fdata-sections -Wno-logical-op-parentheses -std=c++11 -I./ -I/usr/local/include/gtk-2.0 -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libdrm -I/usr/local/include/libpng16 -I/usr/local/include/harfbuzz -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/atk-1.0 -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/include/glib-2.0 -I/usr/X11R6/lib/glib-2.0/include -I/usr/X11R6/lib/gtk-2.0/include -I/usr/X11R6/include/cairo -I/usr/X11R6/include/pango-1.0 -I/usr/X11R6/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gtkglext-1.0 -I/usr/lib/gtkglext-1.0/include -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/lib/i386-linux-gnu/gtk-2.0/include -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -DflagGUI -DflagMT -DflagGCC -DflagSHARED -DflagLINUX -DflagPOSIX -DflagMAIN ide/BaseDlg.cpp -o _out/ide//home/cxl/Scripts/GCCMK.bm-Gcc-Gui-Linux-Main-Mt-Posix-Shared/BaseDlg.o
...
Using umk I tried to rebuild theide but linking fails at -lfontconfig. Fontconfig is installed, but does not get linked. The library resides below /usr/local/lib, but only /usr/lib is included in library path.
Best regards,
Tom
|
|
|
|
|
|
|
|
| Re: Tarball issues [message #47409 is a reply to message #47406] |
Thu, 12 January 2017 23:06 |
 |
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
You have "/home/cxl/" appended because Makefile.in and uMakefile.in were built on the U++ server using umk.
The corresponding script is svn/trunk/uppbox/Scripts/src.
Those lines are what you are looking for:
Quote:
cp -p ~/Scripts/GCCMK.bm ~/.upp/theide
~/bin/umk ~/upp.src/uppsrc ide ~/Scripts/GCCMK.bm -asrXk ~/upp.tmp/upp/uppsrc
mv ~/upp.tmp/upp/uppsrc/Makefile ~/upp.tmp/upp/uppsrc/Makefile.in
~/bin/umk ~/upp.src/uppsrc umk ~/Scripts/GCCMK.bm -asrXk ~/upp.tmp/upp/uppsrc
mv ~/upp.tmp/upp/uppsrc/Makefile ~/upp.tmp/upp/uppsrc/uMakefile.in
Those modifications should fix it:
Quote:
cp -p ~/Scripts/GCCMK.bm ~/.upp/theide
~/bin/umk ~/upp.src/uppsrc ide GCCMK -asrXk ~/upp.tmp/upp/uppsrc
mv ~/upp.tmp/upp/uppsrc/Makefile ~/upp.tmp/upp/uppsrc/Makefile.in
~/bin/umk ~/upp.src/uppsrc umk GCCMK -asrXk ~/upp.tmp/upp/uppsrc
mv ~/upp.tmp/upp/uppsrc/Makefile ~/upp.tmp/upp/uppsrc/uMakefile.in
Committing...
[Updated on: Thu, 12 January 2017 23:11] Report message to a moderator |
|
|
|
| Re: Tarball issues [message #47413 is a reply to message #47404] |
Fri, 13 January 2017 10:19 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi amrein,
It was a fresh install and I have not installed anything 'manually'. I just had to install libnotify and llvm39, but did it with the default package manager.
* Please note that working on TrueOS, or *BSD in general, is not a critical issue for me at the moment. Just wanted to help you in testing. *
Here's the output of commands you asked for:
[tom@trueos-7040] ~% pkg-config --variable pcfiledir gtk+-2.0
/usr/local/libdata/pkgconfig
[tom@trueos-7040] ~% pkg-config --variable pcfiledir fontconfig
/usr/local/libdata/pkgconfig
[tom@trueos-7040] ~% cat "$(pkg-config --variable pcfiledir fontconfig)/fontconfig.pc"
Illegal variable name.
[tom@trueos-7040] ~%
Just for reference, here's the result of locate fontconfig.
[tom@trueos-7040] ~% locate fontconfig
/usr/local/include/fontconfig
/usr/local/include/fontconfig/fcfreetype.h
/usr/local/include/fontconfig/fcprivate.h
/usr/local/include/fontconfig/fontconfig.h
/usr/local/include/qt5/QtPlatformSupport/5.6.2/QtPlatformSupport/private/qfontconfigdatabase_p.h
/usr/local/include/qt5/QtPlatformSupport/5.6.2/QtPlatformSupport/private/qfontenginemultifontconfig_p.h
/usr/local/lib/girepository-1.0/fontconfig-2.0.typelib
/usr/local/lib/libfontconfig.a
/usr/local/lib/libfontconfig.so
/usr/local/lib/libfontconfig.so.1
/usr/local/lib/libfontconfig.so.1.9.2
/usr/local/libdata/pkgconfig/fontconfig.pc
/usr/local/pkg-cache/fontconfig-2.12.1,1-581b37418c.txz
/usr/local/pkg-cache/fontconfig-2.12.1,1.txz
/usr/local/share/doc/fontconfig
/usr/local/share/doc/fontconfig/fontconfig-user.html
/usr/local/share/doc/fontconfig/fontconfig-user.pdf
/usr/local/share/doc/fontconfig/fontconfig-user.txt
/usr/local/share/gir-1.0/fontconfig-2.0.gir
/usr/local/share/licenses/fontconfig-2.12.1,1
/usr/local/share/licenses/fontconfig-2.12.1,1/catalog.mk
/usr/local/share/licenses/fontconfig-2.12.1,1/LICENSE
/usr/local/share/licenses/fontconfig-2.12.1,1/MIT
/var/db/fontconfig
/var/db/fontconfig/1fe06f2352c4cb897117a756a050a9d4-le64.cache-7
/var/db/fontconfig/317e92aa1a4d3e601fb38e2d3c7b366a-le64.cache-7
/var/db/fontconfig/4c599c202bc5c08e2d34565a40eac3b2-le64.cache-7
/var/db/fontconfig/5590eef8711d78f75a1d19f78ae9af8f-le64.cache-7
/var/db/fontconfig/830bb1cbfd3d582459af9eb69ef1dd53-le64.cache-7
/var/db/fontconfig/b505adbf72d7253408dd67084a8aa967-le64.cache-7
/var/db/fontconfig/ba1d92d9e40780c65c2952558e6fa6f5-le64.cache-7
/var/db/fontconfig/bd930d03fc0401d0f1dcfa7b9bdc1687-le64.cache-7
/var/db/fontconfig/CACHEDIR.TAG
/var/db/fontconfig/d3b21a501470a17bfd0b9b6aedc735bd-le64.cache-7
/var/db/fontconfig/ece4193fc5c4a4effb1dc60970b2e31e-le64.cache-7
Finally, please note that the flags flagGCC and flagLINUX were erroneously active, while I assume they should have been flagCLANG and flagBSD.
Best regards,
Tom
|
|
|
|
|
|
|
|
| Re: Tarball issues [message #47418 is a reply to message #47416] |
Sat, 14 January 2017 22:40 |
|
Klugier
Messages: 1117
Registered: September 2012
Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello,
Quote:
Solution: well, I don't know. There is no pkg-config file for freetype in most distributions (no freetype.pc I mean). The only way to handle this efficiently would be to switch to GNU Autoconf and this is not as easy as it sound.
I think it would be not problem to modify Draw package to link against libttf when BSD or FREEBSD is detected. Dose it happen on all BSD distribution or it is related only to True OS?
____________________________________________________________ _________
You can try to modify linking libs in Draw package organizer. This is shown on below screenshot:
Below is the list of all flags that we can handle in package organizer (ide/Core/Host.cpp - line 316):
void LocalHost::AddFlags(Index<String>& cfg)
{
#if defined(PLATFORM_WIN32)
cfg.Add("WIN32");
#endif
#ifdef PLATFORM_LINUX
cfg.Add("LINUX");
#endif
#ifdef PLATFORM_POSIX
cfg.Add("POSIX");
#endif
#ifdef PLATFORM_BSD
cfg.Add("BSD");
#endif
#ifdef PLATFORM_FREEBSD
cfg.Add("FREEBSD");
#endif
#ifdef PLATFORM_OPENBSD
cfg.Add("OPENBSD");
#endif
#ifdef PLATFORM_NETBSD
cfg.Add("NETBSD");
#endif
#ifdef PLATFORM_DRAGONFLY
cfg.Add("DRAGONFLY");
#endif
#ifdef PLATFORM_SOLARIS
cfg.Add("SOLARIS");
#endif
#ifdef PLATFORM_OSX11
cfg.Add("OSX11");
#endif
}
So, as you can see we can make hacks for all BSD related system and only for that using FREE BSD kernel. Dependency in this case is BSD > FREEBSD.
Sincerely,
Klugier
U++ - one framework to rule them all.
[Updated on: Sat, 14 January 2017 22:43] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Tarball issues [message #47421 is a reply to message #47420] |
Sat, 14 January 2017 23:21 |
Tom1
Messages: 1319
Registered: March 2007
|
Ultimate Contributor |
|
|
Hi both,
Thanks for looking into this issue.
From my point of view TrueOS is just a convenient way to quickly install FreeBSD with a usable desktop. Klugier: Please note that the BSD world is not anywhere nearly as fragmented as Linux world is. If FreeBSD is supported, the coverage is already more than adequate. OpenBSD support would be nice, but likely out of reach for now. Please read more on that below.
Supporting TrueOS as a separate system from FreeBSD is in my opinion both unnecessary and wasting energy. If TrueOS differs from FreeBSD in a bad way, just forget TrueOS. However, it would be nice to have FreeBSD working. When I get to the office on Monday, I will try to install a clean FreeBSD and test with that instead of TrueOS. (Or maybe someone have done it already???)
--
I also did a test installation of OpenBSD on Friday, but first found out that the default gcc version on OpenBSD is more or less about ten years old (4.2.x) and no way it's going to support C++11. Also, after installing clang -- which is eventually going to replace gcc on OpenBSD too -- I ran in trouble with problems on thread local storage not being supported. At least that's what the clang compiler thought when compiling Core. I could not really figure out if this is really the case with OpenBSD, or just a clang compatibility issue, but never the less, Upp is not going to work on OpenBSD without substantial effort I guess.
Thanks and best regards,
Tom
|
|
|
|
| Re: Tarball issues [message #47422 is a reply to message #47416] |
Sun, 15 January 2017 00:47 |
Sender Ghost
Messages: 301
Registered: November 2008
|
Senior Member |
|
|
amrein wrote on Sat, 14 January 2017 21:18It's because freetype libraries on BSD are named differently (libttf.so* instead of libfreetype.so*). I found that running 'pkg info -l freetype'.
I guess, that you installed outdated version of FreeType from print/freetype FreeBSD port, which has libttf.so library. The libfreetype.so library installed by print/freetype2 FreeBSD port. Example for v2.7.1:
% pkg info -l freetype2 | grep /lib
/usr/local/lib/libfreetype.a
/usr/local/lib/libfreetype.so
/usr/local/lib/libfreetype.so.6
/usr/local/lib/libfreetype.so.6.13.0
/usr/local/libdata/pkgconfig/freetype2.pc
% pkg-config freetype2 --libs
-L/usr/local/lib -lfreetype
As I understood, the exported Makefile (including for nightly builds) is done for Linux (with flagLINUX). The exported Makefile for FreeBSD (with flagBSD and flagFREEBSD) has other contents. Take a look at configuration of current revision of uppsrc/CtrlCore package (or with using TheIDE), for example:
Toggle excerpt from uppsrc/CtrlCore/CtrlCore.upp file
library(WIN32 !MSC8ARM) "advapi32 comdlg32 comctl32";
library((LINUX | BSD) & !NOGTK & !RAINBOW & !GTK3 & GUI) "gtk-x11-2.0 gdk-x11-2.0 atk-1.0 gdk_pixbuf-2.0 m pangocairo-1.0 fontconfig Xext Xrender Xinerama Xi Xrandr Xcursor Xfixes pango-1.0 cairo X11 gobject-2.0 gmodule-2.0 glib-2.0";
library((LINUX | BSD) & GTK3) "gtk-3.0 gdk-3.0 atk-1.0 gdk_3.0 m pangocairo-1.0 fontconfig Xext Xrender Xinerama Xi Xrandr Xcursor Xfixes pango-1.0 cairo X11 gobject-2.0 gmodule-2.0 glib-2.0";
library(WIN32 !MSC8ARM) "user32 gdi32";
library(LINUX !RAINBOW GUI) "X11 Xrender Xinerama";
library(LINUX !RAINBOW) dl;
library(LINUX !XLFD !RAINBOW GUI) Xft;
library(BSD !RAINBOW) "X11 Xau Xdmcp";
library(BSD !XLFD !RAINBOW) "Xft fontconfig Xrender freetype expat";
library(LINUX !XLFD !SHARED !RAINBOW GUI) "fontconfig Xrender freetype";
library(OSX11) "X11 Xft fontconfig Xrender freetype expat";
library(FREEBSD | DRAGONFLY) xcb;
library(POSIX !NOGTK !RAINBOW GUI) notify;
library(DRAGONFLY) "Xext Xinerama";
Perhaps, you trying to create some universal solution and already know about this information.
There is a devel/upp FreeBSD port, which used for installation of release version. If you look at its contents, you may understand, that it adapts exported Makefile for FreeBSD, uses related configuration flags and generate files for build methods.
There is also a devel/upp-nightly port on the forum for some nightly revision, which was created for other purposes. I updated it to current 10703 revision and it builds fine (on FreeBSD 10.3).
[Updated on: Sun, 15 January 2017 01:12] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
| Re: Tarball issues [message #47427 is a reply to message #47424] |
Sun, 15 January 2017 21:38 |
|
Klugier
Messages: 1117
Registered: September 2012
Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello,
In Makefile.in in 4 line there is following code:
Macro = -DflagGUI -DflagMT -DflagGCC -DflagSHARED -DflagLINUX -DflagPOSIX
Then when we detects that our current operating system is BSD, the following line should have following form
Macro = -DflagGUI -DflagMT -DflagGCC -DflagSHARED -DflagBSD -DflagPOSIX
Can we add there if and detects operating system in makefile. I am not big makefile expert, so I would like to ask?
To detect that we are running on BSD we can call following command:
[www@cb.vu]~> uname -a
FreeBSD cb.vu 7.1-STABLE FreeBSD 7.1-STABLE #2: Wed Jan 30 16:21:05 CET 2009 c@cb.vu:/usr/obj/usr/src/sys/CB i386
Alterantivly, we can do exactly like we do on Core, so detects with 'uname -s' that the operating system is Linux and treat all others like BSD. What do you think Amrein?
Sincerely,
Klugier
U++ - one framework to rule them all.
[Updated on: Sun, 15 January 2017 21:59] Report message to a moderator |
|
|
|
| Re: Tarball issues [message #47428 is a reply to message #47427] |
Sun, 15 January 2017 22:13 |
|
Klugier
Messages: 1117
Registered: September 2012
Location: Poland, Kraków
|
Senior Contributor |
|
|
One more alternative - using compiler version to detects operating system especially BSD:
For clang try:
clang++ -v
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.0.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
For GCC try:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
As you may notice, we are interesting in target field. For clang ("Target: x86_64-pc-linux-gnu") and for GCC "--target=x86_64-linux-gnu". Maybe it will help.
U++ - one framework to rule them all.
|
|
|
|
| Re: Tarball issues [message #47429 is a reply to message #47425] |
Sun, 15 January 2017 22:33 |
|
Klugier
Messages: 1117
Registered: September 2012
Location: Poland, Kraków
|
Senior Contributor |
|
|
amrein wrote on Sun, 15 January 2017 21:32Klugier, I'm modifying a few scripts in Scripts directory. That way, U++ will build out of the box on BSD distributions.
But I still have a big problem: the need to fix Makefile generation with umk.
For now on, I do a manual fix with before running make:
sed -i -e 's|\$\$|$$$$|g' uppsrc/Makefile.in
I don't know how to fix umk. It needs to not just duplicate but quadruplicate the '$' character found in file names when it creates Makefile.
Hello,
The MakeFile code base is hidden in following file ide/Builders/MakeFile.cpp. And probably you are interested in following function (line 11):
static String MakeSourcePath(const Vector<String>& dirs, String fn, bool raw, bool exporting)
Try to play with it - for example replace in fn. If it starts working just post your patch here - to discuss it before committing. You know how to build UMK from TheIDE?
I can try to modify this cpp file to support BSD, but probably I could do it until the next Saturday 
Sincerely,
Klugier
U++ - one framework to rule them all.
|
|
|
|
|
|
| Re: Tarball issues [message #47431 is a reply to message #47425] |
Sun, 15 January 2017 23:09 |
Sender Ghost
Messages: 301
Registered: November 2008
|
Senior Member |
|
|
amrein wrote on Sun, 15 January 2017 20:32For now on, I do a manual fix with before running make:
sed -i -e 's|\$\$|$$$$|g' uppsrc/Makefile.in
I don't know how to fix umk. It needs to not just duplicate but quadruplicate the '$' character found in file names when it creates Makefile.
I tried following sed patch instead:
% sed -i '.bak' -e '/.tpp/s|\$|$$|g' Makefile
But this makes Makefile incompatible with GNU make (gmake on FreeBSD):
% gmake
<...>
gmake: *** No rule to make target 'ide/app.tpp/About$$en-us.tppi', needed by '_out/ide/CLANG-Bsd-Clang-Freebsd-Gui-Main-Mt-Posix-Shared/About.o'. Stop.
I guess, this is not a solution for current (umk/theide) generator of exported Makefile, because on other platforms GNU make may be used. Otherwise, possible to generate BSD and GNU compatible make files with different names: BSDmakefile and GNUmakefile. The GNU make may use GNUmakefile and BSD make may use BSDmakefile first.
The mentioned issue was partially fixed with using compiler generated dependency information, some patch for which I attached in another topic (as a fix for another issue). For example, Clang compiler (on FreeBSD 10.3) escapes "$" character(s) to "$$" for dependencies:
% touch build_info.h
% c++ -MM -c -pipe -Wno-logical-op-parentheses -std=c++11 -DflagGUI -DflagMT -DflagCLANG -DflagSHARED -DflagPOSIX -DflagBSD -DflagFREEBSD -DflagNOGTK -I./ `pkg-config freetype2 -cflags` ide/About.cpp | grep .tpp
Core/topic_group.h ide/app.tpp/all.i ide/app.tpp/About$$en-us.tppi \
ide/app.tpp/AdvancedReplace$$en-us.tppi \
ide/app.tpp/AndroidBuilder$$en-us.tppi ide/app.tpp/Assist$$en-us.tppi \
ide/app.tpp/BSD$$en-us.tppi ide/app.tpp/Blitz$$en-us.tppi \
ide/app.tpp/ConfiguringPackagesAssemblies$$en-us.tppi \
ide/app.tpp/Contact$$en-us.tppi ide/app.tpp/Cpp$$en-us.tppi \
ide/app.tpp/CrossComp$$en-gb.tppi ide/app.tpp/Files$$en-us.tppi \
ide/app.tpp/FindFile$$en-us.tppi ide/app.tpp/Flags$$en-us.tppi \
ide/app.tpp/GPL$$en-us.tppi ide/app.tpp/GettingStarted$$en-us.tppi \
ide/app.tpp/GettingStarted$$ru-ru.tppi ide/app.tpp/IconDes$$en-us.tppi \
ide/app.tpp/IntroductionToUPP$$en-us.tppi ide/app.tpp/Keys$$en-us.tppi \
ide/app.tpp/NewProject$$en-us.tppi \
ide/app.tpp/PackageTemplates$$en-us.tppi \
ide/app.tpp/PackagesAssembliesAndNests$$en-us.tppi \
ide/app.tpp/PackagesAssembliesAndNests$$ru-ru.tppi \
ide/app.tpp/Sponsor$$en-us.tppi ide/app.tpp/Topic$$en-us.tppi \
ide/app.tpp/cmdline$$en-us.tppi ide/app.tpp/esc$$en-us.tppi \
ide/app.tpp/importext$$en-us.tppi ide/app.tpp/index$$en-us.tppi \
ide/app.tpp/index$$ru-ru.tppi ide/app.tpp/install$$en-us.tppi \
ide/app.tpp/install$$ru-ru.tppi ide/app.tpp/macros$$en-us.tppi \
ide/app.tpp/special$$en-us.tppi ide/app.tpp/umk$$en-us.tppi \
ide/app.tpp/upp$$en-us.tppi build_info.h
This works for BSD make just for first run, while dependency information wasn't generated yet (which may be enough for first build without interruptions).
The other possible solution is to rename directories/files with "$" characters, but this also may require to change other parts of source code.
The devel/upp FreeBSD port just uses gmake to build release version, which doesn't have this issue.
[Updated on: Mon, 16 January 2017 13:56] Report message to a moderator |
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sun Apr 26 20:47:18 GMT+2 2026
Total time taken to generate the page: 0.01567 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
This is probably cosmetic issue, but should be fixed.
