Compiling from source with Zero Install
I'm still undecided about how to handle compiling from source with the injector. There are two models I'm considering:
- Each binary interface has a corresponding source interface. Executing a source interface creates a binary package, which can then be added to the binary interface's list of implementations.
- Source is another type of architecture (probably a low-priority one). So, the injector will pick a binary archive for your platform if one exists, or a source archive if one doesn't. Executing a source implementation still runs it, but it just takes longer the first time (sorry, can't remember who suggested this method).
The second one is more automatic in some ways and only requires one interface. On the other hand, it makes it less explicit that a binary archive is being created (that's just a side-effect) so how to create binaries is less obvious. Also, the build-dependencies get mixed in with the execution dependencies.
With the first model things are more explicit. E.g.:
$ 0launch http://site/MyProg-src [ choose version of MyProg and a version of each build dependency ] Compiling in [somewhere]/MyProg-build-tmp Adding local feed [somewhere]/MyProg-build-result/MyProg.xml to http://site/MyProg $ 0launch http://site/MyProg [ new binary runs ]
A window pops up asking you to choose a version of MyProg-src to compile, along with version of gtk-devel, gcc, and anything else needed during the compile. The binary that appears as the result of this doesn't require the GTK headers or the C compiler, but has its own requirements.
Of course, we would have a '--source' flag to automatically find and run the source for a given binary interface.
Some issues to resolve:
- Does the source go in the cache like everything else? In Debian, apt-get source works differently to apt-get install: it just downloads a copy to the current directory without storing it anywhere or requiring root access. Of course, Zero Install doesn't require root access anyway so maybe storing it in the cache is OK.
- How can you edit the source? If it's in the cache, you'll have to make a copy first. Is this the common case, or is compiling an unmodified version the common case? For unmodified versions, it would be better to build straight from the cache, even though it makes the build system a little more complicated.
- Where are 'temporary' files stored? Where is the final binary archive placed? In the current directory?
- What happens after the build? Do the object files hang around in case you want to change something and recompile, or do they get deleted automatically? This comes back to the question of why you are compiling (because no binary is available, or because you wanted to change something).
- Thomas Leonard's blog
- Login to post comments
I may have been the one who
I may have been the one who suggested #2. I like it because src packages are not anything special - like python packages are today. They're just arch neutral. So they match when nothing more specific does.
I don't know why you think that building from source creates a binary archive. But I do understand the issue of the build-time dependencies.
So, adding a little special case for src packages, what about adding (optional) post build steps to clean the build intermediate files as well as the build-time dependencies. It is up to the developer to provide them or not.
Of course, if someone is willing to start building from source, maybe they will do it again and not want to clean things up because that would slow down future updates.
How do you know what the build-time dependencies are anyway? Either add them to the Interface (again making src packages special), or derive them as the difference in dependencies from a binary package - which you might not have if the developer only wants to provide src packages.
Yup, lots to work out here. :)
Source interfaces
I don't know why you think that building from source creates a binary archive
Thinking about this further...
If running a source archive doesn't create binary package that is registered with the injector, how will the injector remember that it exists next time? It would have to recompile from source every time you run the program!
You could get the source's run script to check a build cache each time, but it's easier to let the injector do it (and we can get consistency between packages). Also, I want to make it as easy as possible for people to make binary packages... the easiest way to do this is to make it the default action. APT and RPM generally work this way too (when compiling from source you start by creating a binary, then you install that).
I want to keep the method the same across packages, if possible. For example, I don't like the idea that it's up to the package author whether it's possible to clean up the build. If the injector runs the build process, it knows where the build files went and can clean them up itself.
E.g.: the injector could invoke the source package with:
After the build, the injector stores the location of the target directory as a binary, which will get used for future runs (and can be distributed to others to save them building it).
The user has the option of deleting the build directory, or leaving it. They can enter the build directory and build from there. They'll probably want a writable copy of the source in here if they're going to modify it.
0compile
I've now released 0compile 0.1 now, which can build binaries.
It does indeed use 'src' as the architecture as you suggested, allowing source implementations to be mixed in with binaries if desired, or separated into their own interface with the normal feed mechanism.
Sources are not executable, though - you have to explicitly run 0compile on them. We can probably add a friendly GUI front-end for this at some point.