This looks great! Thanks for the hard work.

Unfortunately, I can't quite use it yet, as I need windows support.

I'll stay tuned : )

daleha: I haven't tested windows at all, but if you are using gmake, you can try to use current version. You will need to set --qtdir to path to your Qt installation (where bin, lib, mkspecs are placed).

Please report if there are any issues.

@starkos: I'd like to get Qt support inside mainline Premake eventually, so I'd like you to review implementation to make sure I've chosen right direction. Note: I'm not going to allow using Qt in one configuration of project and not using it in another.

I don't want to bury Qt stuff deeply in gmake action, but I really need to generate Makefile rules *after* baking.

I think I should save data structure like premake.qt.codegencallbacks in my current implementation into project table, and then write rules in gmake action. So gmake action won't know anything about Qt stuff.

>I'd prepend a "qt" to the API functions to avoid possible conflicts, particularly "uses" should be "qtuses"

I wished to integrate with future uses infrastructure and possibly migrate to it behind the scenes when it's ready. I can rename the function into "qt" (in qmake you do e.g. "QT += network xml" and get selected modules)

>I'd use Premake's API functions.

Problem is that currently I cannot declare API functions outside of api.lua, and it doesn't fell right for me to have Qt-specific stuff there while Qt support is experimental and won't be merged soon. Also, Qt is not a separate language, so I'd preferred to keep Qt-related stuff inside some Qt module in Premake.

If it's appropriate I can add function which will allow to create new APIs outside of api.lua

>Currently, it looks like you can only have one Qt project in your solution

Not really, it affects current project, and next project can redefine it or keep the same (path is relative)

>I'd recommend decoupling this from your make footer patch, so they can be considered separately. For the WiiDev support, I added the make.settings() function, which is currently only called for configuration blocks in gmake_cpp.lua.

Footer patch is almost ready, it also brings other kinds of makefile sections

I like an idea of having make.settings() to do thing like enabling colors or modifying output format (e.g. print "CC filename.c" during compilation), but I can't imagine build rules to be a kind of make settings :)

Trying to explain things briefly, I've written imaginary action-independent Premake extension which adds Qt support using non-existing features, described in opening post:

https://gist.github.com/1350926

I think we should find a reasonable compromise between "the right thing" and the current state of script. Among all kinds of issues mentioned in the beginning of the script, I think only first two are real show stoppers, i.e. non-declarative behavior of "uses" and "mocdir" and friends. This stuff is against Premake spirit and can scare away newcomers. I wish these issues were solved for 4.4 release.

Non-portability of makefiles and absence of support for anything other than gmake are not so significant, I can just embed this script into my Premake plugin for Qt Creator (it uses gmake/gcc on *nix and gmake/mingw on windows under the hood), and start promoting Premake in Qt community as is (probably I need to add Windows/gmake though).

Also, for my particular needs I'd like to have a possibility to specify explicit qtdir per configuration/platform.

Probably they could be solved with post-bake hook(s)

I've reworked my addon. Now it's free from mentioned showstoppers and allows to set qtdir per configuration. So it's almost ready for production ;)

If you want to look at new version, you will find it in the same place as before.

Now I'd like to solve smaller issue. My API allows creation of output directories directories (mocdir, uidir, rccdir, I also want to add qmdir for translations), which ideally should be treated the same way as objdir (processed in builduniquedirs to prevent clash between configurations). However, builduniquedirs is local so I even cannot replace it from outside.

Alternatively, I can intoduce some kind of pattern, e.g. mocdir "%objdir/_moc" (currently I use "$(OBJDIR)/_moc in projects, but it's just a play with make).

Also, Makefiles should support some kind of "list of unique dirs" - when I create rules for mocdir, uidir, and rccdir, I get 3 warnings about overriding commands for target `obj/Debug' if default values are used.

>I can make builduniquedirs accessible

It's not a big deal to remove "local", however I don't think it's a good approach to replace it. Probably it would be better to make it extensible, ie. work not only for objdir.

>I don't understand the second part about the list thing.

Generated makefiles contain distinct targets $(TARGETDIR) and $(OBJDIR), the next code to create them:

$(TARGETDIR):                                                                                                                               
>---@echo Creating $(TARGETDIR)                                                            
ifeq (posix,$(SHELLTYPE))                                                  
>---$(SILENT) mkdir -p $(TARGETDIR)                                        
else      
>---$(SILENT) mkdir $(subst /,\\,$(TARGETDIR))  
endif
 
$(OBJDIR):                                                                                                                                  
>---@echo Creating $(OBJDIR)                                                                                
ifeq (posix,$(SHELLTYPE))                                                     
>---$(SILENT) mkdir -p $(OBJDIR)            
else                              
>---$(SILENT) mkdir $(subst /,\\,$(OBJDIR))                                  
endif

(>--- is tab)

and the next code for clean:

ifeq (posix,$(SHELLTYPE))      
>---$(SILENT) rm -f  $(TARGET)              
>---$(SILENT) rm -rf $(OBJDIR)                    
else              
>---$(SILENT) if exist $(subst /,\\,$(TARGET)) del $(subst /,\\,$(TARGET)) 
>---$(SILENT) if exist $(subst /,\\,$(OBJDIR)) rmdir /s /q $(subst /,\\,$(OBJDIR))    
endif 

It would be better to generalize it to arbitrary list of dirs, and don't create separate rules for same dir (if $(MOCDIR) and others point to $(OBJDIR) and there is a rule for each one, it causes Makefile warnings)

What about builduniquedirs, I can unconditionally put mocdir and friends under objdir, i.e. for

mocdir "_moc"

create $(MOCDIR) as $(OBJDIR)/_moc. Maybe counter-intuitive though.

Also, I need to add special behavior if project is a Qt plugin. Probably I should also use flag for this, shouldn't I?

Hi annulen; I'm trying to build your examples but I get: attempt to call global 'newapis' (a nil value)
I'm using premake-4.4-beta3-windows

Here it is:

http://industriousone.com/topic/full-stack-qt-based-development-premake-...