Re: [qub] cutting down build time: suggestions for a re-org

[stephan b. <st...@ei...>]

On Thursday 30 January 2003 20:04, Marcus vA wrote:
> The dependency on JDK will bring up a new problem: Due to the
> ports-System as well as the SUN-License for the JDK, users have to fetch
> the JDK-source manually (if they are using the ports) and then compile
> the JDK.

Yup, requiring the JDK is certainly not a valid option, especially for BSD 
(i've heard that BSD still has no Java 1.2 port! Is that true?)

> > IMO non-GNU make is just not make.
>
> It is (BSD make), also it's more free than gpl'd gnu make ;-), but uses
> a slightly different syntax, so a focus on other makes should not be
> done, because gnu make is available for nearly all OSses.

Amen.


> > i must admit that i tend to forget all other OSes. :/
>
> Why that?

Because i only use Linux (to be clear: not for moral/ethical reasons, just 
because i happen to like using it). Okay, i use Solaris, but i hate it, and 
my brief experiences with BSD have been pretty horrible (it reminded me too 
much of Solaris!). Windows... i still use that for games, of course. i 
certainly would like QUB to be portable across systems, i just don't always 
take "other systems" into account. i'm glad you're here to remind me of that. 
:)

> > else
> >   # The Solaris, AIX, and Digital Unix default echo programs unquote
> >   # backslashes.  This makes it impossible to quote backslashes using
> >   #   echo "$something" | sed 's/\\/\\\\/g'
> >   #
> >   # So, first we look for a working echo in the user's PATH.
> > ...
> >
> > Eeek!
>
> Not beatiful, but it works (mostly ;-).

Exactly - my point is that i don't want to have to write that type of code by 
hand when autoconf does that so well. i certainly don't mind writing 
build-tree-specific logic in shell code, though.


> > Perhaps we can eliminate some of the stress by explicitely limiting
> > our efforts to a subset of OSes: Linux, BSD and... and... whatever
> > others might be out there. i would never consider losing any sleep
> > over AIX or HPUX ports, for example.
>
> Humm, creating a concept, which gives developers best possibilities for
> enhancing, porting, modifying should be a focus as well as most
> flexibility for us.

Fundamentally i agree completely, i'm just tossing that in as an idea for 
cutting tree maintenance. However, i must admit that most portability-related 
problems have been resolved by people other than me, so i really have no room 
to speak about that ;).


> Cutting down (a bit) effort and making the whole
> thing more static and OS-depending will result in Problems if basic
> functions of tools of the targeted OSses (Linux, BSD) will be redesigned
> and maybe incompatible to previous stuff.

True enough.


> At least, we do not need to think about other OS-ports at this time, but
> should keep in mind, that there are other OSses, where qub could
> possibly run on. So we should not focus on special OS-related stuff, but
> keep the app as portable and standard-conform as well.

Sounds like a good plan to me. :)
(Which reminds me: James, any new word about UBP?)


> > > Using some shell scripts or only one in general would be easier for
> > > us as well as for users (like the one, which already exists).
> >
> > The one shell script or the one user? ;)
>
> There is a user? ;-)

LOL!
Err... i'm not actually sure. :/
Technically speaking, i'm probably not a QUB user, since 95% of my end-user 
gcom interaction is done via gcommaker.


> Ok, thanks.
> I'll check for just using autoconf on BSD and creating
> corresponding shell-stuff in first stage. If someone of you could do
> same on Linux, it would be a great help (especially for merging
> differences from time to time).

Last night i took a look around the tree and found at least one point where 
some re-org is definately in order:

The Qt Designer-gen'd stuff is odd because:

a) They are generated, so they should not really be in the CVS tree.
b) They MUST be in the src tree before automake is run so the .moc files can 
be properly added to Makefile by automake.
c) the build process must "jump around the tree" in hard-to-track ways, so it 
can be make sure that the header files for the generated classes can be 
symlinked into include/... correctly. For example, the files must be gen'd, 
then the include/... dirs have to be updated (so other code will compile), 
then the gen'd files have to be compiled.

Th combination of (a) and (b) means that those gen'd files have to exist in 
CVS, but they also may get re-generated during the build (and then the .moc 
will be regen'd, causing yet more re-compilation). They're a mess, in any 
case.

i'm considering adding a manual step to the build, some type of bootstrap 
script similar to setupthebadmofo.sh, but runnable by people who don't have 
all the dev tools installed. This script would do things like going down the 
tree and generating all need-to-be-gen'd classes. This has to be done before 
'configure', however, and i don't really like that because it forces the user 
to do non-standard things. We could add a check in configure which sees if 
the user has run this script, and run it for them if haven't. i'm not sure 
yet the best way to go about that.


> I do not recommend using bash-related, but sh-compatible stuff, because
> not every user uses bash ;-).

That must be the same guy who's using QUB ;).
To be honest, i'm not familiar enough with Bourne to know how it differs from 
bash (except for `foo` vs $(foo) and that Bourne offers no command-line 
editing). i install bash on all machines i have access to, simply because i 
find sh to be so unfriendly (as if bash is so friendly?!?).  i'll certainly 
stick with non-bash-specific features when i recognize the difference, but i 
must rely on people to point out the differences at times. i'm guessing that 
some of the current makefile shell code (include/make/designer.make) won't 
run under Bourne. :/


-- 
----- stephan
st...@ei... - http://www.einsurance.de
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts