Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Installation and Deployment
  4. Issues compiling c files in Qt creator
Forum Updated to NodeBB v4.3 + New Features

Issues compiling c files in Qt creator

Scheduled Pinned Locked Moved Installation and Deployment
28 Posts 8 Posters 21.2k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G Offline
    G Offline
    goetz
    wrote on last edited by
    #19

    Not quite true.

    @
    HEADERS += plain.h base64.h
    SOURCES += main.cpp base64.c
    @

    This calls g++ (GCC in C++ mode) on main.cpp and gcc (GCC in C mode) on base64.c. The decision is made on the file extension (.cpp or .c). One can tweak that with setting QMAKE_EXT_CPP. The default is .cpp .cc .cxx .C

    http://www.catb.org/~esr/faqs/smart-questions.html

    1 Reply Last reply
    0
    • G Offline
      G Offline
      GordonSchumacher
      wrote on last edited by
      #20

      Actually, there's an even better way:

      Top-level .pro file:
      @
      TEMPLATE = subdirs

      someLib.subdir = someLib
      someLib.makefile = someLib.mak # This may not be named "Makefile"!
      someLib.target = $${QMAKE_PREFIX_SHLIB}someLib.${QMAKE_EXTENSION_SHLIB}

      SUBDIRS = someLib someApp
      @

      someLib/someLib.mak:
      @
      libsomeLib.so:
      gcc foo.c -o libsomeLib.so

      clean:
      rm -f libsomeLib.so

      distclean: clean

      .PHONY: clean distclean
      @

      Note that it will create a bogus, non-functional "someLib/Makefile", but you may simply ignore it.

      I don't believe this is documented, but it's been in qmake for quite a long time (I want to say at least since 4.3.x, but don't quote me on that).

      1 Reply Last reply
      0
      • B Offline
        B Offline
        benardmens
        wrote on last edited by
        #21

        [quote author="GordonSchumacher" date="1291831448"]Actually, there's an even better way:

        Top-level .pro file:
        @
        TEMPLATE = subdirs

        someLib.subdir = someLib
        someLib.makefile = someLib.mak # This may not be named "Makefile"!
        someLib.target = $${QMAKE_PREFIX_SHLIB}someLib.${QMAKE_EXTENSION_SHLIB}

        SUBDIRS = someLib someApp
        @

        someLib/someLib.mak:
        @
        libsomeLib.so:
        gcc foo.c -o libsomeLib.so

        clean:
        rm -f libsomeLib.so

        distclean: clean

        .PHONY: clean distclean
        @

        Note that it will create a bogus, non-functional "someLib/Makefile", but you may simply ignore it.

        I don't believe this is documented, but it's been in qmake for quite a long time (I want to say at least since 4.3.x, but don't quote me on that).[/quote]

        [quote author="Volker" date="1291641995"]Not quite true.

        @
        HEADERS += plain.h base64.h
        SOURCES += main.cpp base64.c
        @

        This calls g++ (GCC in C++ mode) on main.cpp and gcc (GCC in C mode) on base64.c. The decision is made on the file extension (.cpp or .c). One can tweak that with setting QMAKE_EXT_CPP. The default is .cpp .cc .cxx .C[/quote]

        Thanks for all the suggestions, I was unable to go back to the project because of work but I will try the suggestions right away and get back to you.

        Thanks everyone!

        1 Reply Last reply
        0
        • B Offline
          B Offline
          benardmens
          wrote on last edited by
          #22

          Hi all,

          I've tried the options without success so I've uploaded the project if some one could kindly help me out with where I'm going wrong. The link is below

          http://www.wikiupload.com/3XHWP6JG2GXMU1D

          Thanks again everyone for the help so far

          1 Reply Last reply
          0
          • G Offline
            G Offline
            GordonSchumacher
            wrote on last edited by
            #23

            Is that really all of libhaggle? There is no Makefile in that directory, but there is Makefile.in/.ac, which would certainly suggest that it's an Autotools project... but there is no Autoconf.in/.ac, so I can't run automake at all (or at least, mine complains about the lack of those files).

            1 Reply Last reply
            0
            • B Offline
              B Offline
              benardmens
              wrote on last edited by
              #24

              [quote author="GordonSchumacher" date="1292083276"]Is that really all of libhaggle? There is no Makefile in that directory, but there is Makefile.in/.ac, which would certainly suggest that it's an Autotools project... but there is no Autoconf.in/.ac, so I can't run automake at all (or at least, mine complains about the lack of those files).[/quote]

              Hi Gordon, thanks for the quick reply, I actually didn't include them because in my naivety i though they weren't needed. Please find the full haggle folder included. By the way this is being compiled for Maemo (N900). Don't know if that helps. The links are below. They are both the same thing just uploaded to different places for convenience.

              http://www.wikiupload.com/QIPLU200EX9PHGS
              http://rapidshare.com/files/436368610/Policy.zip

              Thanks again every one, really appreciate the help

              1 Reply Last reply
              0
              • G Offline
                G Offline
                GordonSchumacher
                wrote on last edited by
                #25

                Okay, that was way harder than it should have been, and my solution unquestionably qualifies as abusing qmake... but it works!

                I created a "main.pro" in the top-level directory with the following contents:
                @TEMPLATE = subdirs

                haggle_build.subdir = haggle_build
                haggle_build.makefile = Makefile.haggle_build

                PolicyMobile.subdir = PolicyMobile
                PolicyMobile.depends = haggle_build

                SUBDIRS = haggle_build PolicyMobile@

                The "haggle_build.makefile = haggle_build" will cause the top-level Makefile to call "make -f Makefile.haggle_build" in that subdirectory. We need to change the name of the makefile because configure would otherwise clobber it. Note that this will not actually change the name of the file qmake generates there... we'll take care of that in a bit.

                Then I created a subdirectory called "haggle_build". In that directory I placed a file named haggle_build.pro which contains:
                @MAKEFILE = Makefile.haggle_build

                HAGGLE_SRCDIR = ../haggle-0.3

                autoreconf.target = $${HAGGLE_SRCDIR}/configure
                autoreconf.commands = cd $${HAGGLE_SRCDIR} && autoreconf

                aclocal.target = $${HAGGLE_SRCDIR}/aclocal.m4
                aclocal.depends = autoreconf

                automake.target = $${HAGGLE_SRCDIR}/Makefile.in
                automake.depends = autoreconf

                autoheader.target = $${HAGGLE_SRCDIR}/Makefile.in
                autoheader.depends = autoreconf

                libtoolize.target = $${HAGGLE_SRCDIR}/ltmain.sh
                libtoolize.depends = autoreconf

                Makefile.target = Makefile
                Makefile.commands = $${HAGGLE_SRCDIR}/configure
                Makefile.depends = autoreconf aclocal automake autoheader libtoolize

                all.CONFIG = phony
                all.commands = make
                all.depends = Makefile

                TARGET = \\

                QMAKE_EXTRA_TARGETS += autoreconf aclocal automake autoheader libtoolize Makefile all@

                So the MAKEFILE variable changes the name of the makefile to match main.pro's. Most of the rest of the .pro is writing custom targets to ensure that all the Autotools file are up-to-date. The last target, "all", is one which qmake always generates, and is the default build target. I have not found a way to get qmake not to output a section which looks something like:
                @all: $(TARGET)
                $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)@

                Since we defined a custom rule named "all" as well and made it depend on "Makefile", qmake will later on write another rule in the makefile. So we can successfully get the "all" target to invoke make for us; our remaining challenge is to get it not to call the linker!

                So my tactic was to abuse qmake and define TARGET to simply a space. This means that the first "all" rule depends on nothing, and thus will never be run!

                Hope this works for you and helps; I am planning to transfer this nugget to a wiki page...

                1 Reply Last reply
                0
                • B Offline
                  B Offline
                  benardmens
                  wrote on last edited by
                  #26

                  [quote author="GordonSchumacher" date="1292254708"]Okay, that was way harder than it should have been, and my solution unquestionably qualifies as abusing qmake... but it works!

                  I created a "main.pro" in the top-level directory with the following contents:
                  @TEMPLATE = subdirs

                  haggle_build.subdir = haggle_build
                  haggle_build.makefile = Makefile.haggle_build

                  PolicyMobile.subdir = PolicyMobile
                  PolicyMobile.depends = haggle_build

                  SUBDIRS = haggle_build PolicyMobile@

                  The "haggle_build.makefile = haggle_build" will cause the top-level Makefile to call "make -f Makefile.haggle_build" in that subdirectory. We need to change the name of the makefile because configure would otherwise clobber it. Note that this will not actually change the name of the file qmake generates there... we'll take care of that in a bit.

                  Then I created a subdirectory called "haggle_build". In that directory I placed a file named haggle_build.pro which contains:
                  @MAKEFILE = Makefile.haggle_build

                  HAGGLE_SRCDIR = ../haggle-0.3

                  autoreconf.target = $${HAGGLE_SRCDIR}/configure
                  autoreconf.commands = cd $${HAGGLE_SRCDIR} && autoreconf

                  aclocal.target = $${HAGGLE_SRCDIR}/aclocal.m4
                  aclocal.depends = autoreconf

                  automake.target = $${HAGGLE_SRCDIR}/Makefile.in
                  automake.depends = autoreconf

                  autoheader.target = $${HAGGLE_SRCDIR}/Makefile.in
                  autoheader.depends = autoreconf

                  libtoolize.target = $${HAGGLE_SRCDIR}/ltmain.sh
                  libtoolize.depends = autoreconf

                  Makefile.target = Makefile
                  Makefile.commands = $${HAGGLE_SRCDIR}/configure
                  Makefile.depends = autoreconf aclocal automake autoheader libtoolize

                  all.CONFIG = phony
                  all.commands = make
                  all.depends = Makefile

                  TARGET = \\

                  QMAKE_EXTRA_TARGETS += autoreconf aclocal automake autoheader libtoolize Makefile all@

                  So the MAKEFILE variable changes the name of the makefile to match main.pro's. Most of the rest of the .pro is writing custom targets to ensure that all the Autotools file are up-to-date. The last target, "all", is one which qmake always generates, and is the default build target. I have not found a way to get qmake not to output a section which looks something like:
                  @all: $(TARGET)
                  $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)@

                  Since we defined a custom rule named "all" as well and made it depend on "Makefile", qmake will later on write another rule in the makefile. So we can successfully get the "all" target to invoke make for us; our remaining challenge is to get it not to call the linker!

                  So my tactic was to abuse qmake and define TARGET to simply a space. This means that the first "all" rule depends on nothing, and thus will never be run!

                  Hope this works for you and helps; I am planning to transfer this nugget to a wiki page...[/quote]

                  Thanks a lot, there is no way I could have figured that out, I will try that right away and let you know how it goes,

                  Thanks again everyone

                  1 Reply Last reply
                  0
                  • J Offline
                    J Offline
                    jdbastardy
                    wrote on last edited by
                    #27

                    I am also using qmake for my TicTacToe University Project which is coded in C and ncurses. I have no problems compiling C files.

                    http://mattias-cibien.co.cc

                    • Prepare for Qt consequences.
                    1 Reply Last reply
                    0
                    • B Offline
                      B Offline
                      benardmens
                      wrote on last edited by
                      #28

                      [quote author="GordonSchumacher" date="1292254708"]Okay, that was way harder than it should have been, and my solution unquestionably qualifies as abusing qmake... but it works!

                      I created a "main.pro" in the top-level directory with the following contents:
                      @TEMPLATE = subdirs

                      haggle_build.subdir = haggle_build
                      haggle_build.makefile = Makefile.haggle_build

                      PolicyMobile.subdir = PolicyMobile
                      PolicyMobile.depends = haggle_build

                      SUBDIRS = haggle_build PolicyMobile@

                      The "haggle_build.makefile = haggle_build" will cause the top-level Makefile to call "make -f Makefile.haggle_build" in that subdirectory. We need to change the name of the makefile because configure would otherwise clobber it. Note that this will not actually change the name of the file qmake generates there... we'll take care of that in a bit.

                      Then I created a subdirectory called "haggle_build". In that directory I placed a file named haggle_build.pro which contains:
                      @MAKEFILE = Makefile.haggle_build

                      HAGGLE_SRCDIR = ../haggle-0.3

                      autoreconf.target = $${HAGGLE_SRCDIR}/configure
                      autoreconf.commands = cd $${HAGGLE_SRCDIR} && autoreconf

                      aclocal.target = $${HAGGLE_SRCDIR}/aclocal.m4
                      aclocal.depends = autoreconf

                      automake.target = $${HAGGLE_SRCDIR}/Makefile.in
                      automake.depends = autoreconf

                      autoheader.target = $${HAGGLE_SRCDIR}/Makefile.in
                      autoheader.depends = autoreconf

                      libtoolize.target = $${HAGGLE_SRCDIR}/ltmain.sh
                      libtoolize.depends = autoreconf

                      Makefile.target = Makefile
                      Makefile.commands = $${HAGGLE_SRCDIR}/configure
                      Makefile.depends = autoreconf aclocal automake autoheader libtoolize

                      all.CONFIG = phony
                      all.commands = make
                      all.depends = Makefile

                      TARGET = \\

                      QMAKE_EXTRA_TARGETS += autoreconf aclocal automake autoheader libtoolize Makefile all@

                      So the MAKEFILE variable changes the name of the makefile to match main.pro's. Most of the rest of the .pro is writing custom targets to ensure that all the Autotools file are up-to-date. The last target, "all", is one which qmake always generates, and is the default build target. I have not found a way to get qmake not to output a section which looks something like:
                      @all: $(TARGET)
                      $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)@

                      Since we defined a custom rule named "all" as well and made it depend on "Makefile", qmake will later on write another rule in the makefile. So we can successfully get the "all" target to invoke make for us; our remaining challenge is to get it not to call the linker!

                      So my tactic was to abuse qmake and define TARGET to simply a space. This means that the first "all" rule depends on nothing, and thus will never be run!

                      Hope this works for you and helps; I am planning to transfer this nugget to a wiki page...[/quote]

                      Hi Gordon,

                      I've been trying to replicate your solution for the past two weeks with varying levels of success, sometimes it compiles the files and then proceeds to fail. I was wondering if your solution is working for maemo as thats the target platform I'm trying to build for using the MADDE tools. Could you upload your solution so that I can go through it as I dont seem to be making much more headway.

                      Thanks a bunch

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved