Re: [QGIT RFC] Unit tests for QGit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 17, 2008 at 21:30:46 +0100, Marco Costalba wrote:
> On Sun, Aug 17, 2008 at 8:58 PM, Jan Hudec <bulb@xxxxxx> wrote:
> >
> > But as I said, I only have basic infrastructure and am currently looking at
> > what to write tests for and how exactly that test should work. The detection
> > of git vs. stgit branch (does not work for me)
> 
> This sounds as a bug. Could you elaborate on that please ?
> 
> 
> BTW the test for a StGit repo is:
> 
> isStGIT = run("stg branch", &stgCurBranch); // slow command
> 
> in function Git::getRefs() , file git_startup.cpp

Yes, I've seen that command. But it returns true for me even when it's not
a stg branch :-(. I am not sure what the problem there is.

> > Well, I somehow managed -- except I am not sure I dealed with the windows
> > part correctly. What could be improved is maybe if you know how to signal
> > a dependency between two projects. I currently rely on the top-level makefile
> > always calling the subdirs in the order they are specified, but I fear
> > portable recursive make does not really offer any better solution, so qmake
> > can't really do that either.
> >
> 
> Could the following help ?
> 
> http://lists.trolltech.com/qt4-preview-feedback/2004-10/thread00174-0.html

Does help a bit. Thanks.
That is, confirms my suspicion that there is no really correct solution and
remembered me the ordered config option, that I noticed in the documentation
once, but wasn't able to find again when I actually wrote the .pro files.

Added the option and rewound the branch on repo.or.cz.

> > Note: I think I found a bug in qmake here -- when you run qmake at top level,
> > the makefile will call qmake in subdirectories to create makefiles there, but
> > the rule has no dependencies, so it will not remake the makefiles when the
> > .pro files change there.
> >
> 
> I knew that. For my use I always delete Makefiles after modifying any
> of *.pro files, I'm sure it exists a better way but honestly I didn't
> investigate too much on this.

I don't think there's too much to investigate -- it looks like an obvious bug
;-). Unless it's caused by the MAKEFILE setting :-( (I'll have to remove it
and check)

> > Also I don't understand why you set 'MAKEFILE = qmake' in the src/src.pro --
> > it does not seem to be respected, at least when I call it through the
> > top-level qgit.pro (which I now have to when there are 3 subdirs).
> >
> 
> >From http://doc.trolltech.com/4.0/qmake-variable-reference.html#makefile
> 
> MAKEFILE
> This variable specifies the name of the Makefile which qmake should
> use when outputting the dependency information for building a project.
> The value of this variable is typically handled by qmake or qmake.conf
> and rarely needs to be modified.
> 
> I annotated the src.pro file and I found that line belongs from the
> very first version of src.pro, possibly copied from the Qt examples,
> so it smells you are right and we could remove that.

Looks like that. Funny thing is, that normally the makefiles are called
Makefile for me, not qmake, but I did see the qmake files (IIRC when I ran
qmake -recursive). That would mean it takes the value from the top-level .pro
and ignores it in the subdirs.

Regards,
Jan

-- 
						 Jan 'Bulb' Hudec <bulb@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux