[M3devel] Build Server - Plan

[Darko Volaric]

Minimal is cm3 + cm3cg + config file. I'm pretty sure everything else can
be built from that, but someone might correct me.

The required tools issue is solved by only supporting one standard, minimal
toolset (mostly just gcc), installed in a particular place. I'm not trying
to support or test every configuration, just one. It's for people who are
starting from scratch and also serves as a baseline for testing.

I don't understand what your "dependency on X" issue is. As far as I know
there are no external source dependencies in the frontend and the backend
depends only on the gcc source which is in the repository. The build server
only builds the frontend and backend executables, nothing else, so there
are no other dependencies.

If you're talking about building an X Windows application, I still don't
get it. Why do I need to support someone wanting to write an X program? I'm
not supporting people who want to do anything other than run the compiler
on their platform. If they want to make X programs they can download and
configure whatever is needed themselves. The CM3 compiler can compile (but
not link) M3 interfaces and modules for X without having X installed.
That's all I'm trying to support.



On Sun, Aug 16, 2015 at 2:40 PM, Jay K <jay.krell at cornell.edu> wrote:

> What is minimal? sh? gcc? make? python? perl? A large .tar.gz file? X?
>
>
> What is minimal for a user of cm3 vs. a developer of cm3?
>
>
> I bring up X because there are many programs/demos in the distribution,
> including gui ones.
> On many systems, even X is just an "apt get whatever" away.
> And, if we form our .deb correctly, it is fairly automatic.
> On MacOSX current what happens is if you an X program, you automatically
> get a popup prompting you to install.
> On MacOSX current what happens if you try to build an X program, and don't
> have X installed, it fails. We can make it do nothing. We can link to the
> stub -- but then you have to relink after installing X.
>
>
> How to ease that apart? A sort of dependency on X?
> Likely separate packages, like cm3 and cm3-gui?
>
>
> I keep thinking, for a developer but not user of cm3, the bootstrap
> archives should produce autoconf/automake inputs.
> This handles, for example, "how do I invoke the C compiler?" -- even if
> using the gcc backend, we need a C compiler/linker/assembler.
> Imagine if, you know, our config files dropped away entirely.
> Imagine if the config file was generated at install time by autoconf.
> Imagine if we didn't have a small amount of litter in our system as to how
> to link on HP-UX. Or if AIX supported was "inherited" from libtool.
> Basically, libtool supports more than us an overlaps with us. Maybe reuse
> it.
>
>
> Again, I am somewhat positively and negatively obsessed with "the GNU
> build system"
> It is slow and bad to author in, but produces easy to use somewhat slow
> idiomatic results.
>
>
> Also, to reiterate, I believe the point here was the "build server" would
> be complicated, in order to produce easy to use outputs.
>
>
> One also needs to keep in mind the somewhat opposing but common desires:
> install from source vs. install from binaries.
> Install from binaries is faster.
> Install from source is problematic for compilers written in themselves.
> Even gcc.
>
>
>  - Jay
>
>
>
> ------------------------------
> Date: Sun, 16 Aug 2015 13:59:15 -0700
> From: lists at darko.org
> To: m3devel at elegosoft.com; microcode at zoho.com
> Subject: Re: [M3devel] Build Server - Plan
>
> Just like there are different views on how Linux should be set up and thus
> different distributions, there are different views on how CM3 should be
> setup or installed, or at least I have a different view.
>
> I definitely believe in the "effortlessly and mindlessly" thing, and I
> want to take it further than the current installer. In particular I want to
> reduce the external, internal and environmental dependencies so that you
> can build anything, anywhere with just the minimal set of executables and a
> standard set of tools. Others want a more elaborate setup which gives them
> more flexibility; that can also be derived from that same minimal set.
>
>
>
> On Sun, Aug 16, 2015 at 12:27 AM, <microcode at zoho.com> wrote:
>
> On Fri, Aug 14, 2015 at 09:22:08AM -0700, Darko Volaric wrote:
> > The solution for SPARC might be to create a cross-compiler. That's not
> > ideal but would be useful for verifying that things compile for the
> > platform at least, short of having the right hardware.
>
> You should have access to opencsw as Jay mentioned. If not, I can offer
> machine time but I can't keep the machine running all the time. Hopefully
> the current setup (opencsw) is still viable.
>
> > I disagree with your "only for experts" assessment. The point of this
> > server is that you don't have to compiler the compiler and a backend just
> > to get the latest (or even a properly working) compiler. That's the very
> > "expert" work I'm trying to automate.
>
> That is good to hear because from your list of deliverables it seemed to me
> there would still be a lot of tinkering to get a complete install. If you
> are scripting that and it can be built effortlessly and mindlessly from the
> deliverables then good. I think it would be ideal and very nice if people
> could download a turnkey tarball ready to run on their platform, or source
> code ready to build and an installer script that installs the final
> product. Jay mentioned autotools and they are usually far from optimal on
> Solaris because of autotools reliance on so much gnu stuff that is not
> always necessarily present on Solaris but that is the general idea- to be
> able to configure && make && make install with all the standard stuff
> happening like everything being installed in /usr/local/bin|lib|share and
> so
> forth.
>
> > What this system spits out is everything you need to compile anything you
> > want - a complete and working compiler. Not everyone wants or needs to
> use
> > all the packages. If you do, you can. Here are the instructions for doing
> > that: "cd <source dir>; cm3 <options>"
>
> It was probably just my unfamiliarity with the build setup and terms. I'm
> sorry if I wasted anybody's time with this diversion. I have been following
> the mailing list and it looks like Jay and Rodney are mostly discussing
> things with a very small number of regulars. Coming from the outside as I
> do
> I think anybody new is going to have similar questions/misunderstandings of
> how cm3 is built and installed, etc.
>
> > I'll be opening up the server to anyone who wants to do something
> > different. If someone wants to produce tarballs they can setup their own
> > VMs and they will get built too.
>
> Hopefully this can be integrated with what you already have running on
> opencsw.
>
> Thank you.
>
>
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
>
>
> _______________________________________________ M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150816/7bb17a3a/attachment-0002.html>