>This is a bit of a problem. Designed script uses the ability CGIT
>that can
>provide patches from GIT. If references should be local, you'd
>either have
>installed CGIT (or other web interface for git), which will
>provide patches
>from GIT, or would have to be when generating page the patches
>extracted from
>git and stored in local files => this is the problem of the
>current script,
>as mentioned by Tim.
I understand. I looked at this yesterday and realized I have no
local way to generate stand-alone captures of each patch.
Thank you for what you provided. :)
Darrell
>As I mentioned, a side effect of the processing git log in the
>proposed script
>is that each commit is on output in a single line. This would be
>possible to
>simply add the pagination.
>
>For example - adding one simple "sed" to a previously sent crazy
>command for
>listing on the console... see attached script.
Slavek,
Is there a way to change the commit links to the local repo?
The local html page looks fine but the commit links are to the
remote server rather than local.
Yes, I can cd to the affected module and look at the commit, but
having the html page link locally would be nicer.
Darrell
>I could try dusting off my very rusty Java skills one of these
>days and see if I can create a "Hello TQT World", but not tonight.
I seem to recall a collection of files in tdebindings. Perhaps they
are still there. They did not work for me, but just as likely I do
not know how to make them work. If the files do work then we need a
README for dim-lit light bulbs like me.
Primarily all we need are proof-of-concept scripts and compiled
binaries. Use c, python, perl, java, etc. to open some Trinity
dialogs or perhaps open a Trinity app and perform a basic non-
destructive task.
Darrell
>And now it builds. 3 hours wasted just to find out python wants
>flags at the end
>of the call. (You wonder why it is frustrating when things move
>around in TDE..... ;-)
I share your frustration. Been there dome that many times.
And we don't have a collection of demo scripts and C/Java programs
for packagers and developers to test the bindings related apps. We
build this bindings related stuff and have no idea whether anything
actually works.
Darrell
> I have looked at your SlackBuild and I am building with:
Make sure you download the latest. The latest includes the changes
discussed.
> CFLAGS="${CFLAGS} -I/usr/include/tqt -I${TDEDIR}/include -
>I${QTDIR}/include
>-fpermissive" \
> CXXFLAGS="${CXXFLAGS} -I/usr/include/tqt -I${TDEDIR}/include
>-I${QTDIR}/include -fpermissive" \
> echo yes | python2 configure.py \
> -d "${PY2LIB}/sip4_tqt" \
> -y tqt-mt \
> -v /usr/share/sip/tqt
I install sip4-tqt and python-tqt (and everything else except
tqtinterface) to $PREFIX=/opt/trinity.
Rebuild sip4-tqt before rebuilding python-tqt.
My current python-tqt configuration:
if [ "$PREFIX" = "/usr" ]; then
FLAGS="$CPUOPT -L${PREFIX}/lib${LIBDIRSUFFIX} -I/usr/include/tqt -
I/${QTDIR}/include -I${PREFIX}/include"
else
FLAGS="$CPUOPT -L${PREFIX}/lib${LIBDIRSUFFIX} -I/usr/include/tqt -
I/${QTDIR}/include -I${PREFIX}/include -I/usr/include"
fi
echo "yes" | python configure.py \
-b "${PREFIX}/bin" \
-d "$PYTHONLIB/python_tqt" \
-q "$PREFIX" \
-y tqt-mt \
-o /usr/lib${LIBDIRSUFFIX} \
-v /usr/share/sip/tqt \
-u \
CFLAGS="$FLAGS" \
CXXFLAGS="$FLAGS"
As I build to /opt/trinity, visually substitute /opt/trinity with
$PREFIX and you'll see you are building to /usr (the old build
script before the recent patches). The two package configurations
have to be updated similarly otherwise python-tqt can't find sip4-
tqt files.
> What has changed? This used to build flawlessly?
The two packages are now built as modules and a presumption with
that is the two packages no longer conflict with upstream distro
packages. Thus, /opt/trinity/bin/sip no longer overwrites the
distro /usr/bin/sip. Likewise with python-tqt. The module portions
of the packages do not overwrite anything because they are
installed to their own subdirectories.
A side comment: why are you using -fpermissive? I don't use that in
any build scripts.
Darrell
> Both in my sip package and in your listing above, we still have
>/usr/bin/sip,
>so the conflict remains with upstream sip. What did this
>accomplish? All I see
>is that the files were moved into a new 'sip4_tqt' directory --
>was that the
>total intent of the move?
You have /usr/bin/sip because you are installing sip4-tqt to
$PREFIX /usr rather than /opt/trinity.
My sip4-tqt package has /opt/trinity/bin/sip and
/opt/trinity/include/sip.h
The files in my package that are installed to /usr are python site-
packages.
Likewise with python-tqt.
Darrell
> I have time to look at the changes to sip4-tqt, but checking bug
>1790 the patches are crossed out and gone - what is up?
The patches were pushed to git. Typically when patches are pushed
we try in the bug report to remember to tag the patches as
obsolete. That way people do not get confused and try to use a
patch that is already pushed, which then will cause build failures
and confusing messages about asking to reverse the patch.
Darrell
What broke?
This package built fine 10 days ago? It doesn't even begin to build now. Just
the error:
Traceback (most recent call last):
File "configure.py", line 31, in <module>
from sip4_tqt import sipconfig
ImportError: No module named sip4_tqt
Huh?
--
David C. Rankin, J.D.,P.E.