On 06/20/2018 04:03 PM, Matthew R. Trower wrote:
Jon Trulson <j...@radscan.com> writes:
Imake is dead, and I see no point in trying to "take over" and improve
it. Autotools (as others have also mentioned in this thread) is the
way to go moving forward. We might be able to leverage some of the
work X11 did there as well.
Well, my expectation was that we would just keep it working, nothing
more. The advantage to imake is that it is simple. Trying to actually
improve it much past where its at would probably be counter-productive.
Sure, for now. In time though when autotools is the way to build, the
imake stuff will just bitrot as no one will use nor-maintain it. Hence,
it will be removed on that day :)
With autotools, we could get multi-core builds, cross compiler
support, build-time detection of system features, languages, and
capabilities, and much more. We could take advantage of their finer
grained installation support (--bindir=DIR, --libexecdir=DIR,
--runstatedir=DIR, and a dozen others to also resolve the whole "stuff
everything into /usr/dt" issue as well.
Yes, yes, YES =)
I had already been considering some work on parallel make. If autotools
can aid with this in any way, so much the better. It would really help,
especially on my SPARC hardware...
As long as the dependencies are kosher, autotools will handle all that
for you. I have an autotools project that makes several libraries and
executables, and I can easily do "make -j 8" without problems :)
We should (as X11 and Motif did) develop it along side Imake until it
is working well enough to just toss out Imake. We would also get
"make install" working (though this does not have to wait for
autotools integration), and we could eventually get rid of the UDB
databases and their dependencies too.
Yeah, I think so too. I'd rather get chunks of autotools working at a
time, rather than go whole hog all at once.
Yep.
Are we going to go straight for modular packaging as well, or hold off
on this until we have autotools builds working right? I think these are
somewhat separate issues...
They are, and the current UDB files can provide a map for
modularization. But they are separate issues. Modularization is a
packaging issue, not a build issue.
So, I am all for it. A question though, is timing. Should we get a
stable release out first, and then start working on something like
this?
Definitely get a stable release out first. I'm hoping Ulrich will come
back with a green light on the Motif patch soon; everything else on my
end is ready for release.
That was my thinking too.
-jon
Alternatively, we could just keep releasing occasional development
releases until we are ready, but that would mean a stable release
might still be a long way off.
I don't think autotools builds (and all the subtle bugs we might run
into using them) are worth delaying the release for, from an end-user
perspective. I think the only thing that should be holding up release
at this point are fixes for build breakage or moderate-severe end-user
experience bugs. We can always make another release sooner rather than
later if it comes to it. We don't need to wait another two years. =)
-mrt
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
--
Jon Trulson
"Fire all weapons and open a hailing frequency for my victory yodle."
- Zapp Brannigan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
