[Gambas-devel] gbmake. A drop-in replacement to automake

[Sebastian Kulesz]

On Fri, Sep 7, 2012 at 2:17 AM, Sebastian Kulesz <sebikul at ...176...> wrote:
> On Wed, Sep 5, 2012 at 4:01 PM, Benoît Minisini
> <gambas at ...1...> wrote:
>> Le 05/09/2012 13:43, Benoît Minisini a écrit :
>>> Le 05/09/2012 05:02, Sebastian Kulesz a écrit :
>>>> Hi all !!
>>>>
>>>> I really think Gambas is a great language to work with, but lets face
>>>> it, from the point of view of a beginner, distributing an application
>>>> is a pain in the a**. There is no *standard* way to build a project
>>>> (other than executing gbc3/gba3 directly if we let the IDE aside),
>>>> this makes it difficult to create debian packages, PPAs, etc. as they
>>>> all require some sort of autoconf script to manage the process.
>>>> Without the IDE, an user can do much. And with it, this implies
>>>> installing every component it depends on (a total of 15).
>>>>
>>>> To create a PPA of a gambas application, for example, the user has 2
>>>> choices. He can either write a Makefile (more bugs, no portability,
>>>> etc) or create a dummy autoconf package, skim the files and replace
>>>> what is needed (package name, version, etc), and merge it with his
>>>> project.
>>>>
>>>> These are really just a few examples of the problems i faced not so
>>>> long ago. With this in mind, i created this little tool to automate
>>>> the building of gambas apps. It works as a *drop in* replacement for
>>>> make (*seriously*, you can run "make", "make clean", and "sudo make
>>>> install" without a single script, autoconf, automake, m4 macro).
>>>>
>>>> I also wrote the app with Quickly [0] in mind. For example, if you
>>>> want to debianize a project, you can run "gbmake debianize" or just
>>>> "make debianize" and that is it. It will automatically create a
>>>> skeleton debian/ folder which should work out-of-the-box. Maybe a
>>>> "make source" to create a source archive?
>>>>
>>>> I just started it today, so only the building process is really
>>>> implemented (build, clean, install) but I really see a lot of
>>>> potential here. Once it's completed, the autotools package may be
>>>> dropped (it will be completely replaced and the user will have to do
>>>> nothing). Uploading packages to a PPA will be much easier. Users won't
>>>> depend on the IDE to perform administrative tasks, such as building a
>>>> package or a source archive.
>>>>
>>>> I will need some help to port the packaging code in the IDE to work in
>>>> headless mode. I'm trying to make this tool to only depend on the
>>>> interpreter, so no single component has to be installed for it to
>>>> work. This means implementing a custom option parser, and settings
>>>> parser. I have zero knowledge of Slackware, OpenSUSE, Mandriva, Mageia
>>>> and Fedora (and it's derivatives), so i will only be able to port the
>>>> code, but i can't test for any bugs or regressions.
>>>>
>>>> How does it works? It's really simple actually. You will see 2
>>>> Makefiles included. the one named Makefile.1 should be used to install
>>>> the app in the first place.
>>>>
>>>> sudo make -f Makefile.1 install
>>>>
>>>> This command will build the project and install it (/usr/bin/gbmake).
>>>> The second Makefile only wraps the commands sent to "make" to
>>>> "gbmake". It's really the same, but we are all used to type make *,
>>>> aren't we? ;-)
>>>>
>>>> In this case, only adding this Makefile to a project will let "make"
>>>> work out of the box, otherwise, "gbmake" will work just fine.
>>>>
>>>> I will try to have the Debian part finished by the end of the week so
>>>> i can provide a working example, this is just a *proof of concept*,
>>>> and a call for everybody who would like to help. I'm a little skeptic
>>>> about merging this to trunk (even as a branch), as it's a work in
>>>> progress, and it will just confuse the users. Besides, 3.3 is around
>>>> the corner and this will only bring more bugs. Maybe 3.4 if we hurry.
>>>>
>>>> I'm really anxious to hear your comments!
>>>>
>>>> Thanks!
>>>>
>>>> [0] https://wiki.ubuntu.com/Quickly
>>>>
>>>
>>> Good idea, but the problem is code duplication between "gbmake" and the IDE.
>>>
>>> I suggest taking the code from the IDE instead of rewriting your own (or
>>> mix them if yours is better).
>>>
>>
>> Yep. You tried to rewrite things already done by the IDE, but you didn't
>> do it correctly.
>>
>> You should make a list of all project management features you need (how
>> to clean a project, how to compile it...), and I will centralize all
>> these features into an IDE module that will be able to be shared by the
>> gambas make utility.
>>
>> Regards,
>>
>> --
>> Benoît Minisini
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Gambas-devel mailing list
>> Gambas-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
> Okey, here is an initial list. This will let me implement the basic
> set of functions to dump the autotools package.
>
> ---
> Loading .project file to retrieve project type, properties, components
> it depends on, etc.
> Listing installed components
>
> Compile a project (the options are passed from the Application.Args
> array, so there should be a parameter for every option it accepts)
> Package a project once it has been compiled
> Clean a project source tree
> Create a source archive (the output directory should be passed as
> argument, defaults at the cwd, or project root folder)
>
> Generate a .desktop file based on options from the .project file (the
> output directory should be passed as argument, defaults at the cwd)
>
> ---
> As for the packaging functions, IMO, it would be better to rewrite
> them. Please, let me explain first!!
> Archlinux was not so bad, i took the MakeArchPackage and updated
> little parts of the code. It's already finished. the output is
> "pretty" printed, the code is easier to read, and works really well.
>
> Debian is another story. It may "work" well, but in the bottom it's
> full of bugs that are not so evident. What i dislike the most about it
> is that is *assumes* that the deb it is producing will work on any
> distro.
> Firstly, every file inside the debian/ directory is manually created.
> It is also using an outdated (but still supported) format, as it
> specifies debhelper's minimum version as 5, when the debian maintainer
> guide recommends using version 7 (available since lucid or squeeze).
> Second, it specifies the directories and files the package will hold,
> when they should be recognized automatically when building the
> package.
> What about gb.jit? a supported version of llvm is only available in
> quantal or wheezy, which is yet to be released!
>
> I know this is only a paper cut with an easy fix, but every package
> has the same description! "This program is written in Gambas"
>
> The rules file can be replaced by the one available in the dh_make
> template and the standards version should be upgraded.
>
> This are just some of the things i could find while skimming the code.
> I will leave the packaging aside until we can work something out, and
> finish the "autotools" implementation. It's late now, I will send an
> updated source archive tomorrow so you can catch up.
>
> Bye!

Here is a tiny update. PLEASE ignore the packaging modules, i'm
waiting for this common module, but still wanted to sketch some things
beforehand (only the Archlinux module is usable if you have the tool
installed).

I would like you to take a look at the Compiler and Installer module.
Most importantly to the later. There is some duplicate code that i had
to port so i could properly test it, please ignore it too. I wanted to
know if the installer and compiler are well written, and what would
you change. I know there is a *lot* of cleanup to do, but i mean the
algorithm. Am i missing any file? Anything!

I know it works, in fact, i'm already using it to manage the project,
compiling and installing it, even the source package was created using
gbmake.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gbmake-0.0.1.tar.gz
Type: application/x-gzip
Size: 10710 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20120908/ddedeaf3/attachment.bin>