Glen Shennan | 1 Apr 02:09 2011
Picon

Re: Basic question

Overwhelmingly helpful response, thank you!  I did suspect that this would be a waste of my time but I do need to find out what's going on some level, the compilation procedure is all just dark to me right now.  I'll have a flick through the manual.

Glen

On 31 March 2011 23:48, John Spray <jcspray <at> gmail.com> wrote:

Oh, so it's building but you want to know about the internals out of curiosity?  I'd respectfully suggest that your curiosity is misplaced.  Most people who use autotools (myself included) don't write any of this stuff, it all just comes off the shelf apart from the configure.in and Makefile.am files which define what's actually being built.

If you want to learn about build systems then GNU autotools is a bad one to learn.  It's ubiquitous for historical reasons, not because there's anything beautiful about it.  If you are starting from scratch then you should skip autotools and learn CMake or one of the other more modern systems (which don't involve arcane macro languages!).  If you really truly want to know all about auto tools then the official documentation [1] is the place.  However, I can't emphasize enough what overwhelmingly poor use of your time it would be to do so.

John


On Thu, Mar 31, 2011 at 1:31 PM, Glen Shennan <glen.shennan <at> gmail.com> wrote:
Hi,

Thanks for the reply.  I was told earlier to build the source with ./autogen.sh && make which worked (or seemed to).  Now I'm trying to work out what that script is doing, which is calling gnome-autogen.sh which in turns does something with config.in and m4/python.m4.  Unfortunately gnome-autogen.sh and python.m4 are long and look complicated and I have no idea what an m4 macro is anyway so what is going on here is confusing me a bit.  I guess I'm just not sure what's happening in the ./configure and make steps, I'm from DOS so a command like make with no arguments is not natural to me.  If the whole thing is complicated I guess I'm just looking for a good source for documentation; I'm making my way through the relevant sections of the gnome documentation library but the m4 macro home page is gibberish to me at the moment.  "Expanding macros" is not yet in my vocabulary and I'm wondering if there's a way to learn what's going on in this process without reading to much bash script (which I'm also still learning) since I don't think it's too relevant to referencer itself.

Cheers,
Glen



On 31 March 2011 22:28, John Spray <jcspray <at> gmail.com> wrote:
Glen,

What you're looking at is a standard GNU autotools build setup.  You build it with ./autogen.sh && ./configure && make.  If you haven't done this kind of thing before then you probably don't have the required packages, look at the list of dependencies at [1].

(Presumably you've checked this out of version control: the difference between what's in version control and what's in a release tarball is simply that for the tarball the "autogen.sh" step was already run.)

John




On Thu, Mar 31, 2011 at 5:53 AM, Glen Shennan <glen.shennan <at> gmail.com> wrote:
Hi,

I'm very new at this and trying to work my way through the referencer source.  My C++ is rusty (ore) though and I've never used gnome-autogen.sh.  Is there a good tutorial I can have a look at to see how the gnome-autogen.sh and python.m4 macros conspire to get this thing compiled?  I've been searching but can't find anything decent and I've learned enough bash for the moment.  Any quick descriptions are welcome too.  :)

Cheers,
Glen

_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer



_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer



_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer



_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer


_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer
Daniel K. O. | 1 Apr 20:21 2011
Picon

Re: Basic question

Em 31-03-2011 06:48, John Spray escreveu:
> If you want to learn about build systems then GNU autotools is a bad
> one to learn.  It's ubiquitous for historical reasons, not because
> there's anything beautiful about it.  If you are starting from scratch
> then you should skip autotools and learn CMake or one of the other
> more modern systems (which don't involve arcane macro languages!).  If
> you really truly want to know all about auto tools then the official
> documentation [1] is the place.  However, I can't emphasize enough
> what overwhelmingly poor use of your time it would be to do so.

Of course autotools will be the most difficult tool to learn, it is the
one that solves more problems.

I have been dealing frequently with different build systems () for a few
years now, and from my personal experience the only one that is really
reliable is GNU autotools. Finding the proper library file, to
installing (and uninstalling!) in the proper locations, cross compiling,
even something as trivial as setting compiler and linker flags, or
proper dependency tracking... most tools fail miserably at that. And
CMake is not an exception. Oh yeah, CMake DOES use an arcane macro
language too (that manages to be less readable than the mixed M4+shell
script from Autoconf.) If you don't use it then you probably could be
using a Makefile directly. Of course, if a Makefile solves your problem,
there is no reason to switch to a more complicated solution.

I really wish there was something better than autotools, but for now
I'll take it over existing alternatives any day.

--

-- 
Daniel K. O.
"The only way to succeed is to build success yourself."

_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer

Aaron Seilis | 1 Apr 21:09 2011
Picon

Introduction

Hey all,

I'm a M.Sc. student in Canada, and I've been looking for a good tool to
manage references for my thesis. I used Referencer for a brief period,
but eventually looked elsewhere due to the lack of active maintainers.

I just finished reading the posts to the mailing list for the last few
months and I'd like to pitch-in and help. I have some experience with
C/C++/Python, but no experience with the GTK/GTKmm libraries.

After reading the posts, I'm unclear about what has been done in terms
of migration to other hosting/VCS. Does anyone have a repo available to
pull yet?

Aaron Seilis
_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer

Mads Chr. Olesen | 1 Apr 21:23 2011
Picon

Re: Introduction

fre, 01 04 2011 kl. 13:09 -0600, skrev Aaron Seilis:
> After reading the posts, I'm unclear about what has been done in terms
> of migration to other hosting/VCS. Does anyone have a repo available
> to pull yet? 

I have converted all the branches I know of to bzr. They are all at
https://code.launchpad.net/referencer

Then I have merged everything into the
lp:~referencer-devs/referencer/shiyee_andrease_changes (1) branch,
including many of the patches I could find in launchpad.

After that, Antonio Lima has been working further on some gio porting in
his branch at lp:~referencer-devs/referencer/amrlima_gio_port, based on
(1).

I suggest you base your work on one of those branches.

I think at this point we are basically waiting for John to change the
owner of the launchpad project to the team I have created,
"referencer-devs".

--

-- 
Mads Chr. Olesen <mads <at> mchro.dk>

_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer

Aaron Seilis | 1 Apr 22:25 2011
Picon

Library Targets

Hey all,

As you're probably all aware, there is a new major release of
gtk*/GNOME set for next week. What versions of the libraries are we
targeting? I've been able to compile against GTK+ 2.x in the past, but
GTK 3.x is going to take some work. If people want to switch to the
newer libraries, we should probably target the dev releases (they are
in a RC2 stage at the moment, so they shouldn't change much) to avoid
duplicating effort.

Aaron Seilis
_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer

Mads Chr. Olesen | 1 Apr 22:33 2011
Picon

Re: Library Targets

fre, 01 04 2011 kl. 14:25 -0600, skrev Aaron Seilis:
> As you're probably all aware, there is a new major release of
> gtk*/GNOME set for next week. What versions of the libraries are we
> targeting? I've been able to compile against GTK+ 2.x in the past, but
> GTK 3.x is going to take some work. If people want to switch to the
> newer libraries, we should probably target the dev releases (they are
> in a RC2 stage at the moment, so they shouldn't change much) to avoid
> duplicating effort. 

My opinion is we should try to get a release out with our gtkbuilder+gio
porting work, and then target GTK3. But the porting work to GTK3 can
probably start in a separate branch already, if someone is up for the
work :-)

--

-- 
Mads Chr. Olesen <mads <at> mchro.dk>

_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer

António Lima | 1 Apr 23:40 2011
Picon

Re: Library Targets

Sex, 2011-04-01 às 22:33 +0200, Mads Chr. Olesen escreveu:
> fre, 01 04 2011 kl. 14:25 -0600, skrev Aaron Seilis:
> > As you're probably all aware, there is a new major release of
> > gtk*/GNOME set for next week. What versions of the libraries are we
> > targeting? I've been able to compile against GTK+ 2.x in the past, but
> > GTK 3.x is going to take some work. If people want to switch to the
> > newer libraries, we should probably target the dev releases (they are
> > in a RC2 stage at the moment, so they shouldn't change much) to avoid
> > duplicating effort. 
> 
> My opinion is we should try to get a release out with our gtkbuilder+gio
> porting work, and then target GTK3. But the porting work to GTK3 can
> probably start in a separate branch already, if someone is up for the
> work :-)

Yes, I agree. I don't think we have the man power to port to GTK3 and
make a release soon. There's quite a lot of work done since the last
release so a release would be nice.

As for the gio port, although most of it is done, I'm having some
trouble with the Library. The xmlReadIO function takes two callback
functions and I can't make them work with Gio::FileInputStrem... If
anyone has a clue on this, let me know :).

This week and next one are busy but I'll try to hack a bit during the
weekend.

Regards,
António Lima

_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer
Matej Urbas | 2 Apr 00:35 2011
Picon

Re: Library Targets

It was me who did the libxml stuff, so I'll try to take a look at the callbacks today.

Best,
---
Matej

On 1 Apr 2011 22:40, "António Lima" <amrlima <at> gmail.com> wrote:
> Sex, 2011-04-01 às 22:33 +0200, Mads Chr. Olesen escreveu:
>> fre, 01 04 2011 kl. 14:25 -0600, skrev Aaron Seilis:
>> > As you're probably all aware, there is a new major release of
>> > gtk*/GNOME set for next week. What versions of the libraries are we
>> > targeting? I've been able to compile against GTK+ 2.x in the past, but
>> > GTK 3.x is going to take some work. If people want to switch to the
>> > newer libraries, we should probably target the dev releases (they are
>> > in a RC2 stage at the moment, so they shouldn't change much) to avoid
>> > duplicating effort.
>>
>> My opinion is we should try to get a release out with our gtkbuilder+gio
>> porting work, and then target GTK3. But the porting work to GTK3 can
>> probably start in a separate branch already, if someone is up for the
>> work :-)
>
> Yes, I agree. I don't think we have the man power to port to GTK3 and
> make a release soon. There's quite a lot of work done since the last
> release so a release would be nice.
>
> As for the gio port, although most of it is done, I'm having some
> trouble with the Library. The xmlReadIO function takes two callback
> functions and I can't make them work with Gio::FileInputStrem... If
> anyone has a clue on this, let me know :).
>
> This week and next one are busy but I'll try to hack a bit during the
> weekend.
>
> Regards,
> António Lima
>
_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer
António Lima | 2 Apr 00:39 2011
Picon

Re: Library Targets

Sex, 2011-04-01 às 23:35 +0100, Matej Urbas escreveu:
> It was me who did the libxml stuff, so I'll try to take a look at the
> callbacks today.
> 

Great! Thanks Matej!

> Best,
> ---
> Matej
> 
> On 1 Apr 2011 22:40, "António Lima" <amrlima <at> gmail.com> wrote:
> > Sex, 2011-04-01 às 22:33 +0200, Mads Chr. Olesen escreveu:
> >> fre, 01 04 2011 kl. 14:25 -0600, skrev Aaron Seilis:
> >> > As you're probably all aware, there is a new major release of
> >> > gtk*/GNOME set for next week. What versions of the libraries are
> we
> >> > targeting? I've been able to compile against GTK+ 2.x in the
> past, but
> >> > GTK 3.x is going to take some work. If people want to switch to
> the
> >> > newer libraries, we should probably target the dev releases (they
> are
> >> > in a RC2 stage at the moment, so they shouldn't change much) to
> avoid
> >> > duplicating effort. 
> >> 
> >> My opinion is we should try to get a release out with our
> gtkbuilder+gio
> >> porting work, and then target GTK3. But the porting work to GTK3
> can
> >> probably start in a separate branch already, if someone is up for
> the
> >> work :-)
> > 
> > Yes, I agree. I don't think we have the man power to port to GTK3
> and
> > make a release soon. There's quite a lot of work done since the last
> > release so a release would be nice.
> > 
> > As for the gio port, although most of it is done, I'm having some
> > trouble with the Library. The xmlReadIO function takes two callback
> > functions and I can't make them work with Gio::FileInputStrem... If
> > anyone has a clue on this, let me know :).
> > 
> > This week and next one are busy but I'll try to hack a bit during
> the
> > weekend.
> > 
> > Regards,
> > António Lima
> > 
> 
> _______________________________________________
> referencer mailing list
> referencer <at> icculus.org
> http://icculus.org/mailman/listinfo/referencer

_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer
Glen Shennan | 2 Apr 00:50 2011
Picon

Re: Basic question

Well I've been through the first couple chapters of the automake manual and it's cleared a whole lot of things up for me.  I'm happy using the build system the way it is for the moment now, I'll learn more as the need arises.  In my limited experience I've seen autotools most often used so I'm happy with this one.  Thanks for the input.

On 2 April 2011 05:21, Daniel K. O. <danielko.listas <at> gmail.com> wrote:
Em 31-03-2011 06:48, John Spray escreveu:
> If you want to learn about build systems then GNU autotools is a bad
> one to learn.  It's ubiquitous for historical reasons, not because
> there's anything beautiful about it.  If you are starting from scratch
> then you should skip autotools and learn CMake or one of the other
> more modern systems (which don't involve arcane macro languages!).  If
> you really truly want to know all about auto tools then the official
> documentation [1] is the place.  However, I can't emphasize enough
> what overwhelmingly poor use of your time it would be to do so.

Of course autotools will be the most difficult tool to learn, it is the
one that solves more problems.

I have been dealing frequently with different build systems () for a few
years now, and from my personal experience the only one that is really
reliable is GNU autotools. Finding the proper library file, to
installing (and uninstalling!) in the proper locations, cross compiling,
even something as trivial as setting compiler and linker flags, or
proper dependency tracking... most tools fail miserably at that. And
CMake is not an exception. Oh yeah, CMake DOES use an arcane macro
language too (that manages to be less readable than the mixed M4+shell
script from Autoconf.) If you don't use it then you probably could be
using a Makefile directly. Of course, if a Makefile solves your problem,
there is no reason to switch to a more complicated solution.

I really wish there was something better than autotools, but for now
I'll take it over existing alternatives any day.

--
Daniel K. O.
"The only way to succeed is to build success yourself."

_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer

_______________________________________________
referencer mailing list
referencer <at> icculus.org
http://icculus.org/mailman/listinfo/referencer

Gmane